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1 . Introduction 


1 . 1 Overview 

The  National  Software  Works  (NSW)  provides  software 
inplementers  with  a suitable  environment  for  the  development  of 
programs.  This  environment  consists  of  many  software  development 
tools  (such  as  editors,  compilers,  and  deburpers),  runninr  on  a 
variety  of  computer  systems,  but  accessible  through  a sinple 
access-prant inr , resource-al loca t inp  monitor  with  a single, 
uniform  file  system.  By  its  very  nature,  the  NSW  consists  of 
processes  distributed  over  a number  of  computers  connected  by  a 
communications  network.  Ihese  processes  must  communicate  with 
one  another  in  order  to  create  a unified  system.  This  paper 
describes  the  communication  facility  (named  MSG)  which  was 
developed  to  provide  interprocess  communication  for  the 
implementation  of  the  NSW.  The  communications  network 
is  currently  the  ARPANET.  However,  we  have  designed  the 
MSG  facility  to  be  as  .independent  as  possible  of  the  ARPANET 
implementation  so  that  the  concepts  may  be  carried  over  to 
implementations  on  other  networks. 

We  bepin  by  describing  the  more  important  of  the  processes 
which  comprise  NSW  and  discussinr  the  pattern  of  communication 
which  those  processes  require.  We  then  proceed  to  abstract  from 
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1 . 2 NSW  Components 


The  monitor  of  NSW  is 
for  servicing  requests  for 
tool,  opening  a file.  The 
request  is  valid  (using  in 
access  data  base  which 
management  machinery). 


the  Works  Manager, 
system  resources  - 


It  is  responsible 
e . e . , running  a 

Works  Manager  verifies  that  each  such 
this  verification  a rather  elaborate 
serves  as  a domain  for  automated  project 
The  Works  Manager  then  allocates  to  each 


valid  request  th~  necessary  resource, 
involves  either  the  creation  of  a tool 
instance  - i.e.,  the  creation  of  a new 
movement  of  a file  (which  movement  may 
intra-host ) . 


This  allocation  generally 
(e.g.,  editor,  compiler) 
NSW  process  - or  the 
be  either  inter-  or 


p'or  each  user  of  NSW  an  interface  to 
provided  by  a Front  End,  which  may  he  loca 
sequel  we  will  talk  as  if  the  Front  End  we 
communication  to  the  user  is  synonymous  wi 
Front  End.  This  is  not,  however,  an  NSW  s 
Front  End  filters  the  user's  input  stream, 
characters  (e.g.,  control-C  should  not  be 
and  interpreting  system-wide  control  chara 
retype  line,  escape  to  the  Works  Manager, 
Front  End  may  provide  local  parsing  of  the 
language  and,  conceivably,  even  tool  comma 


the  other  components  is 
± to  the  user.  In  the 
re  local,  so  that 
th  communication  to  the 
ystem  requirement.  The 
discarding  bad 
sent  to  TENEX  tools) 
cters  - delete  line, 
etc.  In  addition,  the 
Works  Manager  command 
nd  languages. 


Just  as  users  see  the  NSW  environment  through  the  Front  End, 
so  also  do  iols  see  an  extended  local  system  environment  through 
a Foreman  co  ponent.  Tools  are  software  systems  which  are 
written  for  given  host  - e.g.,  MULTICS.  To  become  NSW  tools 
they  must  be  inserted  into  a slightly  different  milieu.  This 
different  milieu  is  provided  by  a Foreman  component  on  the  tool's 
host.  The  Foreman  provides  the  tool  with  access  to  NSW 
resources,  such  as  NSW  files.  Thus  a tool  gets  NSW  resources  by 
making  a local  call  on  the  Foreman,  which  then  forwards  the 
request  to  the  appropriate  NSW  component.  From  the  viewpoint  of 
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1.3  Patterns  of  communication 

We  v/i  1 1 nov;  describe  the  anticipated  patterns  of 
conmun ica t ion  between  the  NSW  processes . These  communications 
factor  into  six  types: 

. Front  HrJ  - Works  Manarer 
. tool /Foreman  ~ Works  Manarer 
. Works  Manarer  - File  Pac.kare 
. Front  Fnd  - tool /Foreman 
. tool/Foreman  - tool /Foreman 
. File  Packare  - File  Packare 

The  other  possible  pairs  - e.r.,  Front  Fnd  - File  Packare,  File 
Packare  - tool/Fcvnan  - do  not  represent  communication  paths  in 
NSW. 

. Front  Fnd  - Wor* s Mararer 

Communication  '-el  ween  these  tv;o  kinds  of  process  consists  of 
user  reaues ts  for  NSW  resources  (Front  End  to  Works  Manarer)  and 
Works  Manarer  responses  to  such  requests  ('Works  Manarer  to  Front 
End).  Examples  of  such  i 'rests  are:  run  a tool,  copy  a file, 
delete  a file,  etc.  Ti.es?  requests  are  relatively  infrecuent  - a 
user  nay  make  only  a few  per  four.  Ear h request  is  short  - 
almost  all  reouests  can  easily  se  encoded  in  1000  bits.  The 
response  to  each  request  is  also  chert  - crain,  less  than  1000 
bits.  The  tine  required  te  process  a i ocimst  is  renerallv  brief 
- certainly  on  the  order  of  mi  1 1 i seconds,  as  compared  to  the 
minutes  between  requests.  lucre  is  no  necessity  for  a request  to 
be  processed  by  the  same  instance  of  the  Works  Manarer  that 
processed  any  Previous  reauest  (sir.ee  all  instances  of  the  Works 
Manarer  share  the  same  common  data  base).  Hence  a communication 
link  need  not  be  retained  between  a Front  End  and  a Works  Manarer 
between  resource  requests.  Thus  we  can  characterize  Front  End  - 
Works  Manarer  communication  as  a sequence  of  unrelated  elements, 
where  each  element  is  a short  request , a brief  delay,  a short 
response,  and  a lonr  delav  until  the  next  element  of  the 
sequence  . 


. tool/Foreman  - Works  Manager 

These  communications  are  exactly  analnrous  to  Front  End  - 
Works  Manager  comnuniea t ions . A tool  (on  behalf  of  3 user) 
requests  an  NSW  resource  of  the  Works  Manarer.  Examples  of  such 
requests  are:  open  a file,  create  a subsidiary  tool  process, 
deliver  a file,  etc.  As  above,  then0  requests  are  generally  loss 
than  100C  bits,  arc  proeessed  by  the  Works  Manarer  in 
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milliseconds,  have  responses  of  less  than  1000  bits,  and  , re 
relatively  infrequent.  The  only  difference  between  this  pattern 
and  the  preceding  pattern  is  that  tool  requests  are  more  frequent 
than  Front  End  requests,  althourh  the  tine  between  such  req.csts 
is  still  measurable  in  minutes. 

. Works  Manaper  - File  Packape 

These  communications  are  apain  analogous  to  the  above. 
Indeed,  these  requests  (of  the  Works  Manager  to  the  File  Package) 
occur  in  order  to  service  a Front  End  or  tool  request  of  the 
Works  Manaper.  For  example,  when  a tool  asks  the  Works  Manarer  to 
open  a file,  the  Works  Manaper  must  then  ask  a File  Package 
process  to  make  a copy  of  that  file,  possibly  across  the  ARPANET. 
The  tine  ^o  make  a cross-net  copy  of  a file  nay  be  neasured  in 
seconds  (even  in  minutes  for  larpe  files),  but  such  lonp  copies 
are  expected  to  be  infrequent.  Thus,  the  sane  pattern  of  a short 
request  (not  related  to  previous  requests),  a brief  delay,  a 
short  response,  a lorp  delay  holds  for  Works  Manarer  - File 
Packape  communication  also. 

. Front  End  - tool/Foreman 

Communication  between  these  processes  consists  of  user 
commands  to  tools  and  tool  responses  to  users.  In  some  cases 
these  communications  will  fit  into  the  same  pa'^ern  as  the  three 
previous  oases.  Often,  however,  the  pattern  is  different. 
Consecutive  requests  are  related  and  must  be  serviced  by  the  same 
tool.  The  tine  tatween  the  user's  command  and  the  tool's  response 
nay  be  preater  than  the  time  between  the  response  to  the  previous 
command  ar.d  the  issuinp  of  the  next  command.  Also,  the  freauency 
of  user  commands  to  tools  may  be  much  treater  than  the  frequency 
of  either  user  or  tool  requests  to  th*  Works  Manaper.  In 
addition,  the  lenpth  of  a Front  End  - too  1 /Foreman  communication 
may  be  larpe  For  example,  in  a typical  session  a user  ni^ht 
request  the  use  of  a text  editor  ( Front  End  - Works  Manarer 
communication),  ret  a particular  file  to  edit  ( tool /Foreman  - 
Works  Manarer  communication),  and  then  insert  two  hundred  lines 
of  prorran  text  into  that  file.  Thus  Front  End  - tool/Foreman 
communication  is  exoected  to  vary  from  the  infrequent,  short 
request  pattern  to  frequent,  lonp  transmissions  of  information. 

. tool/Foreman  - tool/Foreman 

These  communications  are  relatively  infrequent.  No  tool 
currently  installed  in  NSW  needs  to  tal^  directly  to  another 
tool.  Nevertheless,  deburpinp  tools  for  NSW  as  well  as 
mul t i -process  cools  have  been  proposed  and  are  ^einp  implemented. 
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Such  tools  require  communication  facilities.  We  expect  that 
their  patterns  of  connun ica t ion  will  he  nnalorous  to  Front  Fn  - 
tool  / Foreman  communi  ca  t i ons  . 

. File  Packare  - File  Package 

Some  very  small  fraction  of  these  communications  will 
consist  of  short,  infrequent  messages  - c . r . , a source  File 
Packare  celling  a destination  File  Packare  the  lenrth  and 
encodement  of  a file  - but  the  bulk  of  such  communication  wil1 
consist  of  files  beinr  transferred.  Thus,  we  can  characterize 
this  pattern  as  infreauent  transmissions  of  many  bits. 
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1.4  Model  of  Communication 

vrom  these  expected  patterns  of  communication  we  can 
abstract  a model  of  the  kind  of  interprocess  protocol  that  NSW 
reauires.  Wo  have,  roughly  speaking,  three  patterns  of 
communication : 

. Infrequent  short  transactions  between  previously  unrelated 
processes  (Pattern  1): 

Front  End  - Works  Manager 
tool/Foreman  - Works  Manager 
Works  Manager  - File  Package 

. More  frequent,  longer  t”ansactions  between  related 
processes  (Pattern  2): 

Front  End  - tool /foreman 
tool/Foreman  - tool/Foreman 

. Infrequent,  very  long  transactions  (Pattern  3)* 

File  Package  - F^'le  Package. 


Introduction 

1-6 





MSG  Design  Spec i Pi oa t ion 


1/23/76 


1.5  Modes  of  Connun i on t ion 

MSG  supports  t h e s ° NSW  patterns  of  connunica t ion  by 
providing  two  different  nodes  of  process  addressinr: 

. peneric  addressinr; 

. specific  addressinp; 

and  three  different  nodes  of  communication: 

. nessares; 

. direct  communication  paths  (connections); 

. alarms. 


L’ach  mode  of  process  addressinr  and  communication  is 
intended  to  satisfy  certain  NSW  reouirements  and  to  be  used  in 
certain  kinds  of  situations.  H^weve^,  MSG  itself  does  not  impose 
any  Imitations  on  how  processes  ,r,e  the  various  communication 
modes.  MSG  does  not  interpret  nessares  or  alarms,  nor  oes  it 
intervene  in  communication  on  direct  connections.  The 
interpretation  of  messares,  alarms,  or  direct  connections  is 
ectirsly  *.  matter  for  the  orocess.es  usinr  MSG  to  communicate. 

Generic  addressinr  is  used  by  processes  which  either  have 
nou  communicated  before  or  for  which  the  details  of  any  past 
communica t icn  is  irrelevant.  It  is  restricted  to  the  messare 
mode  of  communication.  A valid  reneric  address  specifies  a 
functional  process  class . When  MSG  accepts  a renericaily 
addressed  messare  it  selects  as  destination  some  process  which  is 
not  only  in  the  generic  cl^ss  addressed  but  has  also  declared  its 
willingness  to  receive  a renericaily  addressed  nessare.  If  there 
is  nc  such  process,  MSG  may  create  one.  Pattern  1 communication 
is  always  initiated  by  the  transmission  of  a renericaily 
addressed  messare. 

A valid  specific  address  refers  to  exactly  one  process  and 
this  address  remains  valid  for  the  life  of  that  process. 

Specific  addressinr  may  be  used  with  rll  three  communication 
nodes.  Specific  addressinr  is  used  oetween  processes  which  are 
familiar  with  each  other.  The  familiarity  is  renerallv  because 
the  processes  ha v communicated  with  each  other  before,  either 
directly  or  throurh  intermediary  processes. 

Messare  exchanre  is  provided  bv  MSG  to  suppor:  the 
requirements  of  pattern  1 communication  and  some  pattern  ? 
communication.  It  is  expected  to  be  the  most  common  node  of 
communication  amonr  NSW  processes.  To  send  a message,  a process 
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addresses  it  by  specifying  the  address  of  the  process  to  receive 
the  message  and  then  executes  an  MSG  ’’send"  primitive  which 
requests  MSG  to  deliver  the  message.  When  MSG  delivers  a message 
to  a process  it  also  delivers  the  name  (i.e.,  specific  address) 
of  the  process  that  sent  the  message. 

The  second  mode  cf  MSG  communication  is  direct  access 
communication.  A pair  of  processes  can  request  that  MSG 
establish  a direct  communica cion  path  between  them.  Direct 
communication  paths  are  provided  to  support  the  requirements  of 
pattern  3 communication , such  as  file  transfers  between  hosts, 
and  some  pattern  2 communication,  such  as  terminal-like 
communication  between  a Front  End  and  tool/Foreman.  (The  ARPANET 
realization  for  a direct  communication  path  is  a host/host 
connection  or  connection  pair.) 

The  alarm  mode  of  communication  is  supported  by  MSG  to 
satisfy  a communication  requirement  typically  satisfied  by 
interrupts  in  other  interprocess  communication  systems.  Alarms 
provide  a means  for  one  process  to  alert  another  process  to  the 
occurrence  of  an  exceptional  or  unusual  event.  Processes  may 
send  and  receive  alarms  much  as  they  send  and  receive  messages. 
However,  tnere  are  significant  differences  between  alarms  and 
messages.  The  rules  that  govern  the  flow  and  delivery  of  alarms 
are  different  from  those  that  govern  the  flow  and  delivery  of 
messages.  In  particular,  the  delivery  of  an  alarm  to  a process 
is  independent  of  any  message  flow  to  the  process.  lhat  is,  the 
delivery  of  an  alarm  to  a process  cannot  be  blocked  by  any 
messages  queued  for  delivery  to  the  process.  Unlike  a message 
which  can  carry  a substantial  amount  of  information,  the 
information  conveyed  bv  an  alarm  is  limited  to  a very  short  alarm 
code.  Thl3  limitation  implies  that  the  deli’  >ry  of  alarms  can  be 
accomplished  in  a way  that  requires  little  ir  the  way  of 
communication  or  storage  resources.  This  makes  it  possible  for 
MSG  to  insure  certain  "priority"  treatment  for  alarms  which  makes 
them  suitable  for  alerting  processes  tc  exceptional  events. 

While  similar  to  traditional  interrupts,  alarms  are  different  in 
one  important  respect:  the  delivery  of  an  alarm  to  a process 

does  not  necessarily  imply  that  the  process  is  subjected  to  a 
forced  transfer  of  control  by  MSG.  For  this  reason,  we  have 
chosen  to  U3e  th3  term  alarm  rather  than  interrupt. 

All  modes  of  interprocess  communication  supported  by  MSG 
follow  the  same  basic  pattern,  which  is  roughly  as  follows: 

1.  One  process  tells  MSG  about  a message  or  alarm  to  be 

sent  or  a connection  to  be  opened.  It  also  specifies  a 
destination  address  and  a signal  by  which  MSG  can 
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inform  it  that  the  message  or  alarm  has  been  sent  o: 
the  connection  opened. 

2.  Another  [-recess  which  matches  the  above  destination 

address  tells  MSG  that  it  is  ready  to  receive  the  sane 
type  uf  communication.  It  also  specifies  a sipnal  by 
which  MSG  can  inform  this  nrocess  that  the  messape  or 
alarm  has  been  received  or  the  connection  opened. 

3-  MSG  sends  the  alarm  or  messape  or  opens  the  connection. 
It  also  signals  the  source  process  that  the  messape  or 
alarm  has  been  sent  or  the  connection  opened  and 
sipnals  the  destination  process  that  the  messape  or 
alarm  has  been  delivered  or  the  connection  opened. 

After  it  receives  the  sipnal,  the  process  receiving  a 
messape  or  alarm  always  knows  the  specific  address  of 
the  sender. 
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1.6  Sequencing  of  Messages 

Normally  MSG  does  not  guarantee  that  messages  sent  from  one 
process  to  another  process  will  be  delivered  to  the  destination 
process  in  the  order  in  which  they  were  sent.  However,  since  it 
is  expected  that  NSW  processes  may  frequently  desire  message 
sequencing,  it  is  possible  for  a process  to  ask  MSG  to  sequence 
certain  messages. 

To  achieve  sequencing  a process  can  specify  when  it  sends  a 
message  that  the  message  is  to  be  sequenced.  MSG  will  guarantee 
that  a sequenced  message  from  process  A to  process  B will  be 
delivered  to  process  B only  after  all  previous  sequenced  messages 
from  process  A have  been  delivered  to  process  B.  A process  may 
if  it  chooses,  intermix  sequenced  and  unsequenced  messages. 

Several  of  the  situations  which  motivate  the  presence  of  the 
alarm  communication  mode  within  MSG  also  require  that  a process 
receiving  messages  be  able  to  distinguish  messages  sent  before  an 
alarm  was  sent  (or  received)  from  those  messages  sent  afterwards. 
That  is,  it  is  often  important  for  a pair  >f  processes  to 
synchronize  a message  stream  with  respect  to  an  alarm. 

To  facilitate  such  message-stream 'alarm  synchronization,  MSG 
supports  the  concept  of  essage  stream  markers.  A stream  marker 
is  an  attribute  of  a message.  When  sending  a message  a process 
may  specify  whether  or  not  the  message  is  to  carry  a stream 
marker.  MSG  guac^ntees  that  a message  M,  sent  from  process  A to 
process  B,  which  carries  a stream  marker  will  be  delivered  to 
process  B only  after  all  messages  sent  by  A prior  to  M have  been 
delivered  to  B and  before  any  messages  sent  after  M by  A. 
Furthermore,  MSG  will  notify  the  receiving  process  B whenever  it 
delivers  a message  that  carries  a stream  marker.  The 
notification  will  be  part  of  th^  information  normally  supplied  Dy 
MSG  to  the  receiving  process. 

When  it  is  necessary  to  achieve  message  stream 
synchronization  after  an  alarm,  a pair  of  processes  can  use  the 
MSG  stream  marker.  This  can  be  accomplished  by  placing  a stream 
marker  on  the  first  message  sent  after  the  alarm  (was  sent  or 
received).  Although  stream  marked  messages  are  provided  by  MSG 
to  simplify  message-stream/alarm  synchronization  by  MSG 
processes,  it  is  important  to  note  that  MSG  itself  places  no 
constraints  upon  how  processes  use  stream  marked  messages. 
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1.7  Host  Incarnations 

The  NSW  is  expected  to  provide  continuous,  2 4 hour  a day,  7 
day  a week  service.  However,  the  various  computer  systems  which 
support  NSW  processes  may  not  provide  such  continuous  service. 
Proper  NSW  operation  requires  that  MSG  be  able  to  determine 
whether  a name  for  a process  refers  to  a process  that  MSG  is 
currently  manarrinp  or  to  an  obsolete  one  which  MSG  managed  durinr 
a previous  period  of  MSG  service  by  the  host  computer  system  in 
question.  (The  term  "incarnation"  is  used  synonymously  with 
"period  of  host  MSG  service"  in  the  remainder  of  this  document.) 
To  enable  MSG  to  distinguish  current  from  obsolete  processes,  an 
MSG  process  name  (more  precisely,  a specific  address)  includes  an 
indication  of  the  host  incarnation  under  which  the  process  exists 
( or  existed ) . 
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1.8  Organization  of  this  Document 

The  remainder  of  this  document  specifies  MSG  in  detail. 
There  are  four  par:s  to  the  specification: 

i.  MSG  process  environment. 

Section  2 defines  in  detail  the  environment  MSG 
provides  to  MSG  processes.  In  particular,  it  defines 
the  set  of  primitives  that  MSG  provides  to  such 
processes . 

ii.  MSG-to-MSG  protccol. 

NSW  is  a mult  :.-computer  system.  Parts  of  MSG  will 
reside  on  the  various  computer  systems  that  comprise 
the  NSW.  The  inter-computer  protocol  used  by  the 
compcnents  of  MSG  in  order  to  support  the  MSG 
primitives  is  specified  in  Section  3- 

iii.  MSG-to-MSG  Protocol  for  the  ARPANET. 

The  initial  implementation  of  the  NSW  will  make  use  of 
the  ARPANET  as  an  inter-computer  communication  medium. 
Section  4 specifies  how  the  ARPANET  host/host 
communication  facilities  are  to  be  used  to  support  che 
MSG-to-MSG  protocol. 

iv.  MSG-to-MSG  Transmission  Formats  for  the  ARPANET. 
Section  5 defines  the  formats  to  be  used  for  the 
transmission  of  MSG-to-MSG  protocol  messages  between 
ARPANET  hosts. 
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2.  MSG  process 
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2.1.  Hosts 

NSW  is  implemented  as  a number  of  processes  runnier 
concurrently  on  a number  of  different  computer  svstems,  called 
hosts.  MSG  on  each  host  can  be  thourht  of  as  an  extension  of  that 
host's  operating  system,  creatine  a new  operating  system  that 
satisfies  the  MSG  design.  Because  MSG  specifies  only  a fraction 
of  the  cost  environment  for  a process,  it  is  generally  true  that 
MSG  processes  will  be  sensitive  to  the  type  of  host  on  which  they 
run  . 

NSW  will  operate  continuously,  but  individual  hr sts  may  not  be 
continuously  part  of  it.  This  can  occur  because  a given  host  is 
not  scheduled  for  continuous  NSW  service,  or  because  the  host  has 
failed.  We  define  a particular  period  of  NSW  service  by  a host  as 
a host  incarnation,  designated  by: 

<host  incarnation  name> 

<host  designatorXincarna t ion  designator^ 

where  <hosh  designator>  is  an  integer  which  uniquely  designates  a 
particular  host  computer  and  <:  carnation  designator>  is  an 
integer  which  designates  this  rticuiar  period  of  NSW  service  by 
this  host. 
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The  form  of  an  MSG  process  is 
the  MSG  design  specifies  only  a 
under  which  the  process  runs.  An 
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resources  such  as  CPU  time . MSG 
following  properties: 

1 . The  process  can  make  at  a.  'as 
2.  The  process  has  a unique  MSG 
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? . 3 • Process  names 

A host  incarnation  supports  a punber  of  MSG  processes.  E=rch 
process  has  a name  of  the  form 

Oprocess  nane>  ::=  <host  incarnation  nameXpener  ic  designators 

<specific  desipnator> 

The  host  incarnation  none  is  the  incarnation  name  of  the  host 
under  which  the  process  is  runninp.  The  pener ic  designator  is  a 
character  strinp  which  characterizes  a process  in  terns  of  its 
functional  relationship  to  other’  processes.  This  characterization 
determines  whether  a process  could  be  chosen  to  perform  a certain 
function.  For  example,  processes  with  peneric  designate  - WM  are 
candidates  for  messapes  which  invoke  Works  Manaper  functions. 
ri  he  specific  designator  is  an  inteper.  A process  name  is  always 
unambiguous;  at  all  tines  it  eit' er  corresponds  to  a sirirle 
process  or  is  invalid. 
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2.4.  Process  address  in,-,  modes 

There  are  two  fundamental  modes  by  which  one  proces  3 nay 
address  another  process:  peneric  and  specific.  A specific 
address  is  always  a process  name.  Generally  process  A will  use  a 
specific  address  for  process  B because  process  A has  had  some 
prior  communication  with  B,  either  directly  or  throuph  some 
intermediary  process. 

A peneric  address,  however,  is  of  the  form: 

Cgenerie  address>  ::=  <host  desipna  torXpeneric  designators  j 

/generic  desipnator> 


Unlike  specific  addressinp,  which  uniqueiy  determines  the 
destination  process,  peneric  addressinp  .implies  a selection  by 
MSG  of  a destination  process  from  a class  of  processes.  This 
selection  allocates  the  destination  process  to  the  communication 
implied  by  the  penerica'ily  addressed  messape . This  is  distinct 
from  process  allocation,  in  which  MSG  creates  and  terminates 
processes . 

The  class  of  processes  f rom  which  MSG  can  oick  a destination 
process  for  a renerically  addressed  messare  is  defined  as 
foil ows : 

1.  If  the  reneric  address  is  of  form 

<host  de sirn a tor>< peneric  desirnator> 
then  the  process  selected  must  be  on  the  designated  host.  If 
<host  desipnator>  is  not  specified  in  the  address,  then  the 
process  may  be  on  any  host. 

2.  The  <reneric  desipnator>  field  of  the  process  name  nust  match 
the  <peneric  desipnator>  field  of  the  reneric  address. 

3.  The  process  must  have  a Recei vepeneric  primitive  call 
pend  in  r . 
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2.5.  Modes  of  information  transfer 

MSG  supports  three  basic  nodes  of  information  transfer  between 
processes:  messages,  alarms,  and  direct  connections. 

A message  is  a string  of  bits  created  in  the  local  memory  of  a 
sending  process.  MSG  sends  the  messare  to  a receiving  process  by 
dupl icat inr  the  bit  string  in  a specified  portion  of  the 
receiving  process 's  local  memory.  MSG  itself  imposes  no  further 
structure  on  messages,  nor  does  it  interpret  the  contents  of 
messages . Messapes  are  the  only  mode  of  communication  which  can 
be  penerically  addressed. 

An  alarm,  like  a message,  is  a strinr  of  bits  created  by  one 
process  and  addressed  to  another  process.  As  with  a messare,  MSG 
transmits  the  bit  strinr  to  the  receiver  process,  which  nas 
designated  beforehand  where  the  bit  strinr  is  to  be  put.  In  other 
ways,  however,  alarms  differ  from  messapes.  First,  an  alarm  is  a 
fixed-length  bit  string  and  is  shorter  than  most  messages . 

Second,  MSG  will  transmit  an  alarm  independently  of  any  message 
traffic  between  sender  and  receiver  processes.  In  fact,  MSG  will 
give  alarms  priority  service  over  messapes.  It  is  anticipated 
that  alarms  will  be  used  to  transmit  information  about  unusual  or 
exceptional  conditions,  while  messa res  and  direct  connections 
will  be  used  to  support  normal  commun ..  cat  ion  . 

A direct  connection  is  a one-  or  tv/o-way  dedicated  channel 
between  two  processes.  MSG  assists  the  processes  in  onenir.^  and 
closing  the  connection,  but  does  not  intervene  in  the  actual  use 
of  the  channel. 

Messapes  are  further  differentiated  by  whether  they  are 
addressed  to  a specific  process  or  to  a generic  class  of 
processes.  Processes  use  different  primitive  rc-illc  to  t.  ..  and 
receive  pener ical ly-addressed  messages  than  t.ne>  use  to  send  and 
receive  specifically-addressed  messapes. 

For  a specifically -addressed  message  it  is  further  possible  to 
specify  either  (but  not  both)  of  two  types  of  soecial  handling: 
sequencing  and  stream  marking.  Normally  MSG  will  not  guarantee  to 
deliver  messages  in  the  order  in  which  they  were  sent.  Sequenced 
messapes,  however,  f rom  process  A to  process  B will  be  deliveied 
to  B in  they  same  order  in  which  they  were  sent  by  A.  A stream 
marker  message  from  A to  B will  not  be  delivered  to  B until  all 
other  messapes  f rom  A to  B have  been  delivered.  Furthermore,  it 
will  be  delivered  to  B before  any  other  messages  to  B sent 
subsequently  by  A. 
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In  all  cases,  MSG  will  inform  the  receiving  process 
special  handling  given  any  message  it  receives. 
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2.6.  MSG  primitive  operations 

Each  host  supports  a set 
processes  that  run  under 
primitives  will  be  host 
sore  tine  later  a reply 
primitive  calls  into  two  classes 
of  the  reply  MSG  makes  to 
primitive  call  the  MSG  rep 
operation  is  complete.  For  the  other  class  of  primitive  call, 
however,  the  MSG  reply  signifies  only  that  the  parameters  of  call 
were  reasonable  enough  for  MSG  to  deduce  what  operation  to 
perform  and  that  MSG  has  agreed  to  attempt  to  perform  this 
operation.  When  this  primitive  operation  is  finally  complete  or 
has  been  aborted,  MSG  will  signal  the  process,  using  a signal 
specified  m the  primitive  call.  We  call  this  uncompleted 
primitive  operation  a pending  event,  where  the  event  in  question 
is  the  completion  or  aborting  of  the  operation.  A pending  event 
has  the  form: 

<pending  event>  ::=  <prinitive><signal><dispXtimer> 
where 

<primitive>  is  the  primitive  operation  to  be  performed 
<signal>  is  a means  by  which  MSG  can  signal  the  process 
that  the  primitive  operation  is  comolete 
<disp>  is  a pointer  to  a field  in  the.  process's  local  memory 
<t.imer>  is  a timer  which  tells  MSG  when  it  can  abort  the 
operation . 

Every  host  will  offer  processes  a set  of  signals  for  use  in 
primitive  calls  that  produce  pending  events.  We  shall  discuss 
signals  at  greater  length  later  in  this  document.  The  disp  field, 
which  MSG  will  have  set  before  it  sends  the  signal,  tells  the 
process  whether  the  primitive  operation  completed  normally  or  was 
aborted . 

The  set  of  all  pending  events  for  a process  is  called  that 
process's  pending  event  set.  When  the  process  makes  a primitive 
call  of  the  second  class,  a pending  event  is  added  to  its  pending 
event  set.  When  MSG  completes  or  aborts  a pending  event,  it  sets 
the  appropriate  disp  field,  sends  the  signal,  and  then  deletes 
the  pending  event  from  that  process's  pending  event  set. 

A process  should  ensure  that  no  two  elements  simultaneously  in 
its  pending  event  set  have  the  same  signal,  but  MSG  will  not 
enforce  this  restriction.  The  simplest  way  for  a process  to 
ensure  tnis  is  never  to  reuse  a signal  in  a primitive  call  until 
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that  signal  has  been  received  from  the  old  call.  It  should  be 
emphasized  that  the  signal  for  an  operation  is  the  only  reliable 
way  for  a process  to  ensure  that  this  operation  has  completed. 
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2.6.1  Primitives  that  create  pending  events 

Many  of  the  following  pri  itives  contain  the  parameter  dt.  This 
is  used  to  create  the  </timer>  field  of  the  pending  event,  and 
either  specifies  a time  interval  in  local  host  clock  units  or 
indicates  that  a default  value  should  be  chosen  by  MSG.  Unless 
the  default  is  specified, 

<timer>  = tc+dt  where  tc  is  the  local  host  clock  time  when 
the  primitive  was  called. 

1 . Sends pec i f i ernes sa re (msgarea , pnam , signal , disp , dt , spnndl ) 
where 

msgarr  - points  to  a message  to  be  sent 
pnam  a process  name 

sphne  specifies  special  handling  for  the  message 

0 - ordirary  handling 

1 - sequenced  message 

2 - stream  marker  message 

This  causes  the  message  pointed  to  by  msgarea  to  be  sent  to 
process  pnam.  At  the  ver>  minimum,  completion  of  this 
primitive  operation  means  that  the  msgarea  has  been  read  by 
MSG,  the  disp  field  set,  and  the  pending  event  deleted  from 
the  sender's  pending  event  set.  Local  hosts  may  opt  to 
guarantee  more,  such  as  that  when  the  primitive  is  completed 
the  foreign  host  has  accepted  the  message. 

2 . Sendgener i ernes sage (msgsrea , genadr , si gna 1 , disp , d i , owai t ) 
where 

msgarea  points  to  a message  to  be  sent 
ge na d r is  a generic  ad d r es s 
qwait  is  a boolean 

This  is  like  Sendspeci f ion  ssage  except  that  here  a generic 
address  is  specified  instead  of  a Process  name,  there  is  no 
special  handling,  and  there  is  the  extra  parameter  qwait. 
Unlike  a Sendspecificmessage , a Sendrenericmessage  may  cause 
MSC  to  create  a destination  process.  Ownit  is  a ooolean; 
setting  it  false  will  cause  MSG  to  accept  the  primitive  only 
if  there  is  a process  available  with  a Receiver eneric 
primitive  pending. 
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. Recei ve s pe cific message (ms pare a, srcnam, si pnai,disp,dt,spbrdl) 
where 

msgarea  points  to  a block  of  local  memory  in  which  MSG 
will  out  a message 

srcnam  points  to  a field  of  local  memory  which  MSG  will 
set  to  the  process  name  of  the  sender 

sphndl  points  to  a field  of  local  memory  which  MSG  will 
set  to  the  special  handling  class  of  the  message 
being  received: 

0 - ordinary  handling 

1 - sequenced  message 

2 - stream  marker*  message 

If  the  primitive  completes  normally,  i.e.  if  the  specified 
signal  is  received  and  the  disp  field  does  not  indicate  an 
error,  then  nsgarea  will  contain  a message  which  was  sent  by 
a Sendspecif icmessage  primitive  call  by  some  process.  Srcnam 
will  contain  the  name  of  the  process  that  sent  the  message, 
and  sphndl  will  show  if  the  messape  was  sequenced  or  was  a 
stream  marker. 

4.  Receive  generic  messape  (msgarea  , srcnam  , signal  , disp , dt ) 
where 

msgarea  points  to  a block  of  local  memory  in  which  MSP  will 
put  a message 

srcnam  points  to  a field  of  local  memory  which  MSG  will 
set  to  the  process  name  of  the  sender 

This  is  like  Recei vespecif icmessage  except  that  here  the 
message  received  was  sent  by  a Sendgener i cmessape  primitive 
instead  of  a Sendspeci f icmessage  primitive.  There  is  also  no 
special  handling  field. 
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5.  Sendalarm (acode, pnam, signal, disp) 
where 

acode  is  an  alarm  code 
pnam  is  a process  name 

This  sends  the  alarm  code  acode  to  the  process  named  pnam. 
When  this  primitive  completes,  the  disp  field  will  indicate 
one  of  the  following  outcomes: 

1.  OK.  Either  the  alarm  was  delivered  to  the  process  or  it 
was  queued  and  will  be  the  next  alarm  to  be  delivered  to 
the  process. 

2.  Rejected.  Process  pnam  is  not  accepting  alarms  at  all 
now,  or  another  alarm  is  already  queued  for  this  process, 
or  sorre  error  has  occurred. 

6 . Ena b leal arm (a code ,srcnam, signal, disp) 
where 

acode, srcnan  point  to  fields  of  local  memory 

This  enables  the  process  to  receive  an  alarm.  When  the  alarm 
is  received,  acode  will  be  set  to  the  alarm  code  and  srcnam 
will  be  set  to  the  name  of  the  alarm  sender.  In  order  for  an 
alarm  to  be  received,  not  only  must  an  Enablealarm  primitive 
be  pending  but  also  the  iaccept  boolean  state  for  this 
process  must  be  true.  This  boolean  value  is  changed  by  the 
primitive  Aceeptalarms . 
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7 . Openconn (conn type , conn id , pnam , sipnal , disp , dt ) 
where 

conritype  is  a connection  type 
TELETYPE 

BINARY  SEND-RECEIVE(s) 

BINARY  SEND ( s ) 

BINARY  RECEIVE ( s ) 
where  s is  a byte  size 
ccnnid  is  a connection  identifier 
pnam  is  a process  name 

This  opens  a connection  of  type  conntype  to  process  pnam. 

The  connection  will  be  identified  by  connid.  In  ”der  for  the 
primitive  to  complete  normally,  process  nnam  must  also 
execute  an  Openconn  primitive  addressed  to  this  process,  with 
the  same  connid  and  a compatible  conntype.  Some  hosts  may 
return  a host-dependent  identifier  for  the  connection. 

8.  Cl os eoon n( con n id, pnam, signal, disp, dt) 
where 

connid  is  a connection  identifier 
pnam  is  a process  name 

This  refers  to  the  connection  created  before  by  the  primitive 
Openconn ( conntype , connid , pnam . If  the  connection  was 
never  opened,  Closeconn  will  abort  with  an  error  code  in  the 
disp  field.  If  the  corresponding  Openconn  is  still  pending, 
the  Openc.nn  also  will  abort.  Whatever  the  outcome,  however, 
when  the  Closeconn  primitive  completes,  the  connection,  if  it 
ever  existed  at  all,  will  be  closed. 

9.  Terminal ionsignal ( tsignal , disp ) where 

tsignal  is  a signal 

If  this  primitive  ever  completes,  i.e.  if  tsignal  is  ever 
received  then  it.  should  be  taken  as  a request  by  MSG  for  the 
process  to  terminate.  The  disp  field  may  be  used,  at  host 
option,  to  specify  why  the  termination  is  beinp  requested. 
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2.6.2  Primitives  that  do  not  create  pending  events 

1 . Stopme ( ) 

This  primitive  indicates  that  the  process  wishes  to 
terminate.  Control  will  never  return  from  this  primitive. 

The  process  will  he  terminated  by  MSG  as  soon  as  possible. 
Well-behaved  processes  will  ensure  that  their  pending  event 
sets  are  empty  before  issuing  this  primitive. 

2.  Rescind ( rsigral ) 
where 

rsignal  is  a signal 

This  is  used  to  delete  a pending  primitive  operation.  The 
parameter  rsignal  must  be  the  signal  of  a pending  event,  i.e. 
an  uncompleted  primitive  operation.  If  the  Rescind  call 
returns  successfully  then  the  corresponding  primitive  will 
not  occur  and  rsignal  will  not  be  sent.  The  Rescind  may  fail 
because  the  primitive  operation  is  partially  complete  and  it 
is  too  late  to  stop  it,  or  because  rsigr-dl  no  longer 
corresponds  to  a pending  event.  The  latter  case  generally 
means  that  the  corresponding  primitive  has  already  completed. 
It  is  a host  option  what  primitives  may  be  rescinded  at  all. 

Some  hosts  may  wish  to  return  an  event  handle  with 
rescindable  primitive  calls.  In  this  case,  the  call  will  he 
Rescind ( event  handle). 

3.  Acceptalarns(aaccept) 

Each  process  has  a boolean  state  value,  iaccept.  If  an  alarm 
is  sent  to  a proces^  whose  iaccept  state  is  false,  the 
Sendalarm  will  fail  with  a disposition  indicating  that  thc- 
process  is  not  accepting  alarms.  If,  however,  iaccept  is  true 
then  the  Sendalarm  will  either  match  an  Enablealarm,  be 
queued,  or  be  rejected  because  another  alarm  is  already 
queued  for  this  process.  Acceptalarms  sets  iaccept  to  the 
value  of  qaccept. 

4.  Resynch ( pnam ) 

If  MSG  had  been  rejecting  sequenced  messages  to  process  pnam 
due  to  failure  of  a sequenced  message  transmission,  then  MSG 
will  now  stop  doing  so. 
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2.7.  Signals 


Each  host  provides  for  processes  running  under  it  a set  of 
signals.  A signal  is  a means  by  which  MSG  can  inform  a process 
that  some  event  has  occurred,  in  particular  that  MSG  has 
completed  some  primitive  operation. 


Different  hosts  will  offer  different  signals,  but  all  signals 
must  satisfy  certain  criteria: 

1.  At  any  point  in  time,  the  process  can  determine  whether  or 
not  the  signal  has  been  received. 

2.  Signals  must  be  distinguishable,  i.e.  if  one  of  several 
possible  signals  has  been  received,  the  process  must  be  able 
to  determine  which  one. 

3-  Signals  are  local.  A signal  to  one  process  does  not 
directly  affect  any  other  process. 


The  restrictions 
variety  of  signals 
section  to  further 
host.  We  list  here 
provide.  These  are 


listed  above  allow  hosts  to  specify  a wide 
for  processes.  It  is  not  the  function  of  this 
specify  what  signals  will  be  available  on  any 
some  examples  of  signals  that  a host  might 
strictly  examples;  they  imply  no  MSG 


rot  return 
occurred . 


from  the 


memory  nonzero 
could  be  the 


channel  n when  the 


requirement  that  these  particular  signals  be  supported: 

1 . Block/Unblock 

The  process  waits  and  control  does 
primitive  call  until  the  event  has 

2.  Flag 

MSG  sets  a field  in  the  process 's  local 
when  the  event  has  occurred.  This  field 
<disposit ion>  field  itself. 

3.  TENEX  PSI  on  channel  n 
On  TENEX,  MSG  sends  nn  interrupt  on  PSI 
event  has  occurred. 

H.  Flag  plus  TENEX  PSI 

MSG  sets  a field  in  the  process's  local  memory  nonzero 
then  sends  an  interrupt  on  ?n  agreed-upon  PSI  channel 
which  is  the  same  for  all  signals  of  this  type.  This 
differs  from  example  3 in  that  here  different  signals 
cause  interrupts  on  the  sane  channel.  Because  TENEX 
queues  PSIs  on  a channel  only  one  interrupt  deep,  some 
PSIs  nay  be  lost  if  MSG  sends  several  signals  of  this 
type  sufficiently  close  to  each  other  in  time.  With 
care,  a process  can  handle  the  resulting  race  without 
undue  difficulfv. 
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2.3  Information  transmittal 

The  sending  of  messages  and  alarms  and  the  openinp  and  closinr 
of  connections  all  involve  a pairing  of  compatible  primitive 
operations  in  the  pending  event  sets  of  (usually)  different 
processes.  Such  a pairing  defines  an  .interchange  of  information 
between  two  processes  which  MSG  must  cause  to  happen.  Tne 
possible  pairings  are: 

1.  Specifically-addressed  message 
This  pairs  the  primitives 

Sendspecif icmessage (ma , pb , . . . ) in  process  pa 
Receivespeeif icmessage (mb , snam , . . . ) in  process  pb 

This  causes  the  message  pointed  to  by  ma  to  be  transmitted  by 
MSG  to  process  pb  and  put  into  the  memory  area  pointed  to  by 
mb.  In  addition,  snam  in  process  pb  will  bo  set  to  pa  so  that 
the  receiving  process  will  know  the  name  of  the  sending 
process . 

2.  Alarm 

This  pairs  the  primitives 
Sendalarm ( acode , ub , . . . ) in  process  pa 
Enablealarm( cdval  snam,...)  in  process  pb 

This  pairing  is  possible  only  if  the  boolean  state  variable 
iaccent  in  process  pb  is  true.  This  causes  the  alarm  code 
acode  to  be  transmitted  f^om  process  pa  to  process  ob  and  put 
into  field  cdval.  In  addition  snam  will  be  set  to  pa,  the 
name  of  the  sending  process. 

3.  Qener ical ly-addressed  message 
This  pairs  the  primitives 

Sendgenericmessage (ma  , ger.adr  , . . . ) in  process  pa 
Receivegenericmessape (mb , snam , . . . ) in  process  pb 

This  is  like  a specifically-addressed  message  pairing  except 
that  here  genadr  is  a ren^ic  address  which  matches  process 
name  pb  instead  of  being  pb  directly. 
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4.  Opening  a connection 
This  pairs  the  primitives 

Openconn ( ta , connida , pb , . . . ) in  process  pa 
Openconn ( tb , connidb , pa  , . . . ) in  process  pb 
where 

connida  = connidb 

l } and  tb  are  compatible  connection  types: 

1.  ta  : tb  = TELETYPE 

2.  ta  = tb  = BINARY  SEND-RECEI VE( s ) 

3.  ta  = BINARY  SEND(s) 

tb  ^ BINARY  RECEIVE(s) 
where  s is  a byte  size. 

This  opens  a connection  of  the  indicated  type  between 
processes  pa  and  pb.  The  connection  will  be  hereafter 
identified  to  both  processes  as  connida  (=  connidb). 

5.  Closing  a connection 
This  pairs  the  primitives 

Closeeonn (connid , pb ,...  ) in  process  pa 
Closeeonn ( connid , pa ,...  ) in  process  pb 

This  will  close  for  both  processes  the  connection  between 
them  which  is  identified  by  connid. 

These  pairings  define  tasks  that  MSG  is  to  perform,  but  they 
allow  MSG  hosts  a great  deal  of  freedom  in  scheduling  computer 
time  and  resources  to  the  multitude  of  concurrent  operations  they 
must  perform.  Me  must,  however,  specify  a few  more  rules: 

1.  Fairness.  MSG  will  not  grossly  favor  any  one  process,  mode  of 
communication,  or  particular  operation  over  any  other. 
Exceptions  are: 

a.  Alarms  will  be  favored  over  messages. 

b.  Transmission  of  messages  with  special  handling 
attributes  may  be  delayed  until  other  related  messages 
have  been  transmitted. 

2.  Access  to  communication.  A process  must  always  be  able  to 
have  in  its  pending  event  set: 

a.  One  message  send  primitive. 

b.  One  message  receive  primitive . 

c.  One  alarm  send  primitive. 

d.  One  alarm  enable  primitive. 

e.  One  primitive  to  open  or  close  a connection. 

3.  Efficiency.  W .thin  limits  set  by  the  above  rules,  MSG  will 
arrange  its  workload  so  as  to  perform  it  in  a reasonably 
efficient  manner. 
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2.9  Sequencing  of  messages 

As  noted  in  Section  1.6,  MSG  normally  does  not  guarantee 
that  a collection  of  messages  sent  from  one  process  to  another 
process  will  be  delivered  to  the  destination  process  in  ths  order 
in  which  they  were  sent.  Some  applications  will  require  that  the 
messages  between  two  processes  be  sequenced.  In  such  cases,  the 
communicating  processes  could  observe  a private  protocol  to 
insure  proper  sequencing  of  messages.  However,  since  it  is 
expected  that  processes  ,iu  frequently  desire  message  s quencing, 
it  is  possible  for  a process  to  ask  MSG  to  sequence  certain 
messages  . 

To  achieve  sequencing  a process  can  specify  when  it  sends  a 
message  that  the  message  is  to  be  sequenced.  MSG  will  guarantee 
that  a sequenced  message  from  process  A to  process  B will  be 
delivered  to  process  B only  after  all  previous  sequenced  messages 
from  process  A have  been  delivered  to  process  B.  A process  may, 
if  it  chooses,  intermix  sequenced  and  unsequenced  messages. 

The  sending  and  receiving  discip1ines  required  of  MSG  to 
support  sequenced  messages  are  discussed  below.  Processes  should 
be  aware  that  a cost  is  associated  with  the  use  of  the  message 
sequencing  option;  that  cost  will  be  reduced  message  throughput. 

MSG  cannot  guarantee  that  every  message  will  be  delivered. 
(The  destination  host  may  be  temporarily  inaccessible,  the 
destination  process  may  spontaneously  disappear,  the  message  nay 
be  timed  out,  etc.)  When  MSG  is  unable  to  deliver  a normal, 
unsequenced  message,  the  sending  process  is  signalled  and 
notified  (via  the  disposition  information  normally  supplied  by 
MSG)  that  the  message  could  not  be  delivered.  The  sending 
process  can  then  take  whatever  action  it  feels  is  appropriate 
with  respect  to  the  message  in  question. 

Sequencing  introduces  an  additional  complexity  here 
since  a sequenced  message  is  not  independent  of  other  messages  in 
the  sequence.  To  illustrate  the  nature  of  the  problem,  suppose 
that  process  A has  attempted  to  send  process  B the  sequenced 
messages  Ml,  M2,  M3,  M^4 , M5.  Furthermore,  suppose  that  MSG 
successfully  delivers  Ml  but  is  unable  to  deliver  M2.  What 
should  MSG  do  with  M3,  M4,  and  M5?  In  particular,  its  inability 
to  deliver  M2  does  not  necessarily  mean  that  MSG  will  be  unable 
to  deliver  the  remaining  messages  in  the  sequence.  Delivery  of 
M3,  M4  and  M5  without  M2  may  confuse  process  B;  processes  A and 
3 are  communicating  via  sequenced  messages  presumably  because 
sequencing  is  important.  Therefore,  MSG  will  not  attempt  to 
deliver  the  remaining  pending  sequenced  messages. 
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If  MSG  cannot  deliver  a sequenced  message  from  process  A to 
process  B,  it  will  stop  the  flow  of  sequenced  messages  to  process 
B from  process  A until  process  A takes  some  explicit  action  to 
"resynchronize"  the  message  sequence.  MSG  does  this  by  marking 
process  A as  being  out  of  synchrony  with  process  B after  a 
sequenced  message  from  process  A to  process  B fails.  MSG  will 
then  abort  all  pending  sequenced  Sendspeci f icmessage  primitives 
in  process  A 's  pending  event  set  which  are  addressed  to  pr  ’ess 
B.  Furthermore  it  will  reject  all  such  primitive  calls 
subsequently  made  by  A until  A r^ synchronizes  the  message 
sequence  with  B by  executing  the  primitive  Hesynch(B). 

As  noted  ir  Section  1.6,  in  situations  in  which  an  alarm  is 
transmitted  or  received,  it  is  often  important  for  a pair  of 
processes  to  identify  a point  in  a stream  of  messages  between 
them  corresponding  to  "where"  the  transmission  (or  receipt)  of 
the  alarm  occurred.  To  facilitate  such  message/alarm 
synchronization,  MSG  supports  the  concept  of  message  stream 
markers.  A stream  marker  is  an  attribute  of  a message.  When  a 
process  sends  a message  it  can  specify  whether  or  not  the  message 
is  to  carry  a stream  marker.  The  default  is  no  stream  marker. 

MSG  guarantees  that  a message  M.  sent  from  process  A to 
process  B,  which  carries  a stream  marker  will  be  delivered  to 
process  B only  after  all  messages  sent  by  A prior  to  M have  been 
delivered  to  B (or  have  been  determined  by  MSG  to  be 
undeliverable)  and  before  any  messages  sent  after  M by  A. 
Furthermore,  MSG  will  notify  the  receiving  process  B whenever  it 
delivers  a message  that  carries  a stream  marker.  The 
notification  will  be  part  of  the  Information  normally  supplied  by 
MSG  t o the  receiving  process.  We  emphasize  that  MSG  itself 
places  no  constraints  upon  how  processes  use  stream  markers. 
However,  we  expect  that  standards  regarding  their  use  will  be 
adopted  for  NSW. 

MSG  observes  a aueuing  discipline  with  respect  to 
Receivespeci f icmessage  primitives.  The  Receivespec i f icmessage 
primitives  executed  by  a process  are  to  be  satisfied  in  the  order 
in  which  they  art  issued  in  the  sense  that  the  first 
Receivespeci f icmessage  should  be  satisfied  by  the  first  message 
MSG  accepts  for  tne  process,  the  second  by  the  second  message, 
etc.  We  note  that  this  does  not  necessarily  imply  that  the 
signals  associated  with  a collection  of  pending  receives  will  be 
delivered  to  the  receiving  process  in  the  order  in  which  the 
receives  were  satisfied. 
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In  addition,  we  note  that  this  MSG  receiving  discipline  does 
not  imply  that  messages  from  a given  sending  process  will  be 
delivered  in  the  order  in  which  the  sending  process  sent  ^hem. 

If  in-order  delivery  is  required,  the  sending  process  must 
request  "sequenced"  or  "stream  marker"  handling.  When  sequencing 
for  a message  is  requested,  the  sending  MSG  observes  sendinp 
discipline  whereby  it  transmits  the  message  only  after  the 
receiving  MSG  has  accepted  all  previous  sequenced  messages  (from 
the  sending  process  to  the  receiving  process).  Similarly,  when 
stream  marking  for  a message  is  requested,  the  sending  MSG 
observes  a sending  discipline  whereby  it  transmits  the  message 
only  after  the  receiving  MSG  has  accepted  all  previous  messages 
from  sender  to  receiver  and  additionally  transmits  no  further 
messages  from  sender  to  receiver  until  the  receiving  MSG  accepts 
this  message.  These  sending  disciplines,  together  with  the 
receiving  discipline  described  above  and  always  followed  by  MSGs, 
is  sufficient  to  insure  in-order  delivery  of  sequenced  and  stream 
marked  messages. 
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2.10.  Process  creation  and  termination 

To  create  a process  MSG  performs  the  following  operations: 

1 . MSG  assigns  a process  name  to  the  process  and  creates 
an  empty  pending  event  set  for  it. 

2.  MSG  creates  the  process  on  the  host  operating  system. 

3-  MSG  starts  the  process  in  some  host -dependent  agreed-upon 
initial  state. 

An  MSG  host  may  create  processes  for  one  of  only  two  reasons: 

1.  In  order  to  fulfill  its  obligation  tc  find  a destination  for 
a generically  addressed  message. 

2.  As  part  of  system  initialization  or  restart. 

To  terminate  a process,  MSG  performs  the  following  operations: 

1.  MSG  marks  the  process  for  termination  in  such  a way  that 
it  will  no  longer  be  a candidate  for  any  communication 
from  other  processes  and  such  that  it  is  blocked  from 
issuing  any  mere  MSG  primitives. 

2.  MSG  completes  or  rescinds  all  elements  in  the  process's 
pending  event  set. 

3-  MSG  deletes  the  process  from  the  host. 

4.  MSG  forgets  about  the  process. 
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2.11  Summary  of  terms 

We  present  here  a brief  summary  of  the  terms  defined  in 
this  section: 

1.  Host  incarnation  name 
<host  incarnation  name>  ::= 

\host  des i pm  a t or >< incarnation  design ator> 

2.  Process  name 
<process  name>  : : = 

<host  incarnation  naireXpeneric  designator Xspeci f ic  designator> 

3 . Generic  addi ess 

<gcnerie  address'  ::=  <host  desi^natorXgeneric  desipnator>  ! 

<generic  designator> 

4.  Generic  designator 

<generic  designator>  ::=  character  string 

L3 . Specific  designator 

<specific  designator>  ::=  integer 

6.  Host  designator 

<host  desi,: ,:ator>  : : - integer 

7.  Incarnation  designator 
<incannation  desi^.ia  tor>  ::=  integer 
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3.  MSG  -to -MSG  Protocol 


This  section  specifies  the  inter-hcst  MSG  protocol  which 
supports  the  primitives  provided  to  processes  manaped  by  MSG. 

The  concern  in  this  section  is  the  information  communicated 
between  MSGs  rather'  tnan  how  it  is  communicated.  This  section 
assumes  the  existence  of  a bi-directional  communication  path 
between  each  pair  of  MSG  host  systems.  Issues  such  as  how  these 
MSG-to-MSG  oaths  are  supported  by  ARPANET  communicat ion 
capabilities  or  how  MSG-to-MSG  messapes  are  delivered  are  the 
subjects  of  Sections  4 an'1  5. 
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3.1.  Transaction  Identifiers. 

The  completion  of  an  inter-host  MSG  transaction  (such  as  the 
transmission  of  a message  or  an  alarm)  o-enerally  requires  a 
protocol  exchange  that  involves  several  inter-MSG  messages.  When 
an  MSG  initiates  an  inter-host  transaction  on  behalf  of  a process 
it  manages,  it  generates  an  identifier  for  the  transaction  which 
it  places  into  the  inter-MSG  message  which  initiates  the 
transaction.  In  addition,  the  initiating  MSG  generally  places 
the  name  of  the  initiating  process  into  the  inter-MSG  message. 


Whe 
a transa 
ident if i 
transact 
between 
ident if i 
into  the 
which  re 
ident if i 


n an  MSG  responds  to  an  inter-MSG  message  that  initiates 
ction,  the  responding  MSG  includes  the  transaction 
er  chosen  by  the  initiating  MSG  in  its  response.  If  the 
ion  in  question  is  one  that  requires  further  interaction 
the  MSGs,  the  responding  MSG  generates  a second 
er  (its  identifier)  for  the  transaction  and  places  it 
respen,3e  message.  All  subsequent  inter-MSG  messages 
fer  to  the  transaction  will  include  both  transaction 
ers  . 


MSG-to-MSG  Protocol 
3-2 


MSG  Design  Specification 


1/23/76 


3.2.  On  the  use  of  "source"  and  "destination". 

Most  inter-MSG  messages  are  transmitted  to  support 
interactions  between  a pair  of  processes.  Consequently,  most  of 
these  messages  include  the  names  of  two  process  and  many  include 
two  transaction  identifiers.  In  the  specification  that  follows, 
we  adopt  the  convention  of  using  "source"  when  referring  to  a 
process  or  transaction  identifier  managed  by  the  initiating  MSG 
and  "destination"  when  referring  to  a process  or  transaction 
identifier  managed  by  the  responding  MSG.  "Source"  is  then 
relative  to  the  initiator  of  the  transaction;  it  is  not  relative 
to  the  sender  of  a particular  message  in  the  series  of  protocol 
messages  needed  to  carry  out  the  transaction. 
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3.3-  MJG-to-MSG  Protocol  Items. 

In  the  specifications  of  inter-host  MSG  protocol  items  that 
follow,  the  items  are  grouped  according  to  the  primitives  they 
support.  In  these  specifications  all  information  exchanged 
between  MSGs  is  explicitly  represented  as  parameters  of  the 
various  protocol  messages.  In  some  cases  some  parameters  may  be 
implicit  from  the  protocol  exchange  context  and  are  therefore 
redundant.  Section  5 defines  the  transmission  formats  for  the 
protocol  items  in  detail. 


1.  MSG-to-MSG  protocol  for  interprocess  messages 
( Send Spec i f icMes sage , Recei veSpecif icMessage , 
Sen d Gene r icMessage , Recei veGener icMessage ) 


MESS  (source-process,  destination-process,  source-ID, 

dest inat ion-ID , handling,  length,  message-data) 

This  initiates  an  inter-MSG  message  transaction.  It 
indicates  that  the  source-process  has  requested  that  a message 
(defined  by  length,  message-da ta ) be  delivered  to  the 
destination-process.  The  source  ID  is  the  identifier  selected  by 
the  source  MSG  to  identify  the  message  transaction.  The 
destination  MSG  should  include  source-ID  in  all  communication 
concerning  this  message  transaction.  The  dest inat ion-ID  is  empty 
if  it  is  unknown;  it  tak;s  on  meaning  for  Interactions  requiring 
more  than  a simple  request  and  acknowledgement  (see  descriptions 
of  MESS-HOLD,  HOLD-OK , MESS-CANCEL  and  XMIT  below).  The 
dest ination-ID  is  an  identifier  selected  by  the  destination  MSG 
for  the  message  transaction.  The  handling  parameter  specifies 
the  special  handling  (if  any)  required  by  the  receivxng  MSG  in 
order  to  properly  deliver  the  message.  Examples  of  special 
handling  include:  include  a synchronization  marker  with  message; 

MESS-HOLD  not  an  acceptable  response  (see  below);  MESS-HOLD 
acceptable  and  this  MESS  is  an  implicit  HOLD-OK  (see  below). 

Protocol  requires  the  destination  MSG  to  promptly  acknowledge 
MESS  with  one  of  the  following  three  messages. 


MESS-OK  ( source-process , destination-process,  source-ID) 

This  response  to  MESS  indicates  that  the  destination  MSG 
takes  full  responsibility  for  buffering  the  message  data  and 
subsequent  delivery  of  the  data  to  the  destination-process.  This 
reply  implies  'chat  destination-process  is  currently  a valid  name. 
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It  does  not  imply  that  the  message  data  has  been  actually 
received  by  destination-process,  nor  does  it  guarantee  that 
destination-process  will  ever  accept  the  data. 


MESS-REJECT  (source-process,  destination-process,  source-ID, 
reason ) 

This  response  to  MESS  indicates  that  the  destination  MSG 
will  not  accept  the  request  for  the  transaction  identified  by 
source-ID.  Reason  indicates  the  reason  for  rejection.  Possible 
reasons  include:  no  such  process,  no  buffer  space,  too  many 

messages  already  queued  for  this  process,  etc.  The  reason 
supplied  might  be  one  which  attempts  to  stimulate  retransmission 
by  the  source  MSG  if  the  rejection  is  known  to  be  of  a temporary 
nature . 


The  following  fcur  MSG-MSG  protocol  items  provide  an 
important  extension  to  the  basic  message  transmission  discipline 
of  MESS,  MESS-OK,  and  MESS-REJ  described  above.  These  additional 
protocol  items  are  motivated  by  the  need  for  flexible  flow 
control  within  MSG.  Their  inclusion  introduces  complexity  to  the 
protocol.  However,  the  flexible  flow  control  they  support  is 
sufficiently  important  to  iustify  this  complexity. 


MESS-HOLD  ( source-process , dest inat ion-process  , source-ID, 
destination -ID) 

This  response  to  MESS  indicates  that  the  destination  MSG 
will  not  accept  the  message  data  associated  with  the  specified 
message  transaction  but  that  it  will  remember  that  the  message 
transaction  has  been  requested  and  at  some  time  in  the  future 
will  ask  the  initiating  MSG  to  retransmit  the  message  data.  The 
dest ir;a tion-ID  is  the  identifier  selected  by  the  destination  MSG 
for  the  message  transaction.  Both  source-ID  and  destina tion-ID 
should  be  included  in  any  subsequent  MSG-to-MSG  communication 
concerning  this  message  trac  action. 

Protocol  requires  that  the  source  MSG  acknowledge  the  MESS-HOLD 
promptly  with  one  of  the  following  two  messages. 


MSG-to-MSG  Protocol 
3-5 


MSG  Design  Specification 


1/23/76 


HOLD-OK  (source-process,  destination-process,  sour*ce-ID, 
destination-ID) 

This  reply  to  MESS-HOLD  indicates  that  the  source  MSG  agrees 
to  buffer  the  message  associated  with  the  transaction  specified 
by  source-ID  and  destination-ID.  The  destination  MSG  will 
remember  the  pending  message  transaction  and  request  transmission 
of  the  message  when  it  is  able  to  accept  the  message  data. 


MESS-CANCEL  (source-process,  destination-process,  source-ID, 
destination-ID,  reason) 

This  reply  to  MESS-HOLD  indicates  that  the  source  MSG  is 
unwilling  to  buffer  the  specified  message.  In  addition,  it  may 
be  used  by  a source  MSG  to  indicate  that  it  has  ceased  buffering 
a message  which  it  had  previously  agreed  to  buffer. 


XMIT  (source-process,  destination-process,  source-ID, 
destination-ID) 

This  is  used  by  a destination  MSG  to  request  a source  MSG  to 
transmit  a message  previously  buffered.  The  XMIT  signals  that 
tie  message  will,  in  all  probability,  be  successfully  accepted. 

On  receiving  a XMIT,  the  source  MSG  is  expected  to  transmit  the 
message  identified  via  a MESS  message  (using  the  specified 
source-ID  and  destination  ID  to  identify  the  transaction  in 
question).  All  legal  responses  to  a MESS  request  are  appropriate 
for  the  redelivery. 

A destination  flSG  can  send  a MESS-REJ  rather  than  an  XMIT  in 
order  to  abort  a message  transaction  for  which  the  message  is 
buffered  at  the  source.  It  might  choose  to  do  this  if  the 
destinat ion -process  terminates  without  requesting  the  message. 

We  note  that  since  a destination  MSG  can  utilize  the 
MESS-HOLD  option,  it  may  be  important  to  provide  processes 
managed  by  MSG  means  to  declare  that  a MESS  request  be  accepted 
or  rejected  immediately  (i.e.  not  held)  by  a destination  MSG. 

This  concept  is  not  currently  supported  at  the  process-MSG 
interface  level;  should  it  become  important  to  do  so,  the 
"handling"  Darameter  of  the  MESS  item  will  be  used  to  support  the 
concept  at  the  inter-MSG  protocol  level  . 
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2.  MSG-to-MSG  Protocol  for*  Interprocess  Alarms 
(SendAlarm,  EnableAlarm) 


ALARM  (source-process,  destination-process,  source-ID, 
alarm-code ) 

This  initiates  an  inter-MSG  alarm  transaction.  It  indicates 
that  the  source-process  has  requested  that  an  alarm  be 
transmitted  to  the  destination-process.  A few  bytes  of  data 
(alarm-code)  are  to  be  conveyed  to  the  destination-process  along 
with  the  alarm.  The  ALARM  message  should  bypass  the  flow  control 
mechanism  applied  to  normal  interprocess  message  transactions 
(MESS).  Source-ID  is  the  identifier  selectee  by  the  source  MSG 
to  identify  this  transaction. 

Protocol  requires  that  one  of  the  following  two  messages  be  sent 
promptly  to  acknowledge  the  ALARM. 

ALARM-OK  (source-process,  destination-process,  source-ID) 

This  response  to  an  ALARM  request  indicates  that  the  alarm 
request  has  been  accepted  by  the  destination  MSG.  It  does  not 
mean  that  the  alarm  has  been  received  by  the  destination-process; 
it  may  be  the  case  that  the  alarm  is  never  actually  delivered  to 
the  destination-process. 


ALARM-REJECT  (source-process,  destination-process,  source-ID, 
reason ) 

This  resoonse  to  an  ALARM  request  indicates  that  the 
destination  MSG  refuses  to  accept  the  alarm.  Reason  indicates 
the  reason  for  rejection  (e.g.  incorrect  destination  process 
name,  process  not  accepting  alarms,  another  alarm  is  already 
queued , et c ) . 
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3.  MSG-to-MSG  Protocol  for  Direct  Access  Communication 
(Openconr,  Closeconn) 

Because  of  the  symmetric  nature  of  the  following  three 
protocol  messages,  we  change  our  conventions  with  respect  to 
"source"  and  "destination".  In  the  description  of  these  three 
items,  "source  process"  always  indicates  the  process  local  to  the 
sending  MSG  and  "destination  process"  always  indicates  the 
process  at  the  receiving  MSG.  The  same  convention  is  used  for 
the  transaction  ID  fields. 


C0NNECT10N-0DEK  (source-process,  destination-pro cess, source-ID, 
destinat ion-ID , user-connect ion-ID , type, 
source-socket ) 

This  message  indicates  that  the  source  process  desires  to 
establish  a direct  communication  path  to  the  destination-process 
of  the  "type"  specified.  The  source-ID  is  the  identifier 
selected  by  the  source  MSG  to  identify  the  operations  concerned 
with  establishing  and  breaking  the  connection (s ) . Destirat ion-ID 
is  empty  when  unknown. 

("For  implementations  v/hich  make  use  of  the  ARPANET,  the 
source-socket  specifies  the  socket(s)  at  the  source  MSG  host 
which  is  (are)  to  be  used  in  establishing  the  connection  which 
implements  the  communication  path.  Protocol  states  that  the 
ARPANET  RFCs  reauired  to  establish  the  connect  ion ( s ) are  to  be 
exchanged  immediately  after  both  source  and  destination  MSGs  have 
agreed  to  the  connection  (by  exchanging  matching  CONNECTION-OPEN 
messages ) . ] 


CONNECTION-CLOSE  (source-process,  des t ina t ion -process  , source-ID, 
destina  on-ID,  reason) 

This  protocol  message  indicates  that  the  sending  MSG  wants 
to  close  the  connection  identified  by  source-ID  and 
des t inat ion- ^D . Protocol  specifies  that  the  receiver  should 
close  the  crnnec^ion  and  acknowledge  the  request  with  a matching 
CONNECTION- CLOSE.  CONNECTION-CLOSE  may  be  sent  to  abort  a 
connection  which  has  not  yet  been  completely  opened.  Reason 

indicates  the  reason  the  connection  is  being  closed.  Possible 
reasons  include:  orocess  requested  close,  byte  size  mismatch, 

type  mismatch,  and  entry  timeout. 
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CONNECTION-REJECT  ( source-process . destination-process, 
dest inat  ?’ on-ID  , reason) 

This  item  is  used  to  reject  a CONNECT ION -OPEN  or  a 
CONNECTION-CLOSE  request.  It  does  not  require  an 
acknowledgement.  Reason  indicates  the  reason  for  rejection. 
Possible  reasons  include:  no  such  destination;  no  such 

connection.  The  transaction  identifier  returned  is  the 
"source-ID"  for  the  request  being  rejected. 


4.  MSG-to-MSG  Protocol  for  Obtaining  Process  Status 
(Get-status  primitive) 

An  MSG  primitive  to  be  used  to  obtain  information  regarding 
the  status  of  an  MSG  process  is  to  be  spe^fied  in  the  future. 

The  "get-status"  primitive  will  not  be  required  in  the  firsc  MSG 
implementation.  The  following  describes,  in  general  terms,  three 
protocol  items  which  are  intended  to  support  the  "get --status " 
primitive  . 


SEND-STATUS  (source-process,  destination-process,  source-ID) 

This  protocol  message  requests  the  status  of  the 
destination-process  on  behalf  of  the  source-process . Source-ID 
is  the  identifier  selected  by  the  source  MSG  for  the  status 
transaction . 

Protocol  requires  that  one  of  the  following  two  messages  be 
promptly  sent  in  acknowledgement  of  SEND-STATUS. 


STATUS-OK  ( source-process , dest ina t ion -process  , source-ID, 
status-words ) 

This  returns  the  status  information  requested  by  the  source 
MSG.  The  information  to  be  included  in  the  status  report  has  not 
yet  been  completely  specified.  We  expect  that  it  will  include 
the  state  of  destination-process  including  pending  Sends  and 
Receives  as  well  as  pending  alarms. 

[Note:  it  may  not  be  desirable  to  allow  a process  to  obtain 
detailed  status  information  about  processes  with  which  it  is  not 
actively  communicating.  The  precise  access  controls  (if  any) 
that  are  required  for  the  Get-status  primitive  will  be  defined  in 
the  f uture . ] 
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STATUS-REJECT  ( source-process , destioat ion-process , source-ID, 
reason  ) 

This  response  is  used  to  indicate  the  rejection  of  a 
SEND-STATUS  probe  request.  Reason  indicates  the  reason  for  the 
rejection . 


5.  Miscellaneous  MSG-to-MSG  Messages. 

The  following  MSG  to  MSG  messages  are  provided  because  they 
have  proven  useful  in  communication  system  implementations  and 
for  experimental  extensibility. 


NOP 

This  message  is  a no-operation.  ±c  has  no  effect  and  is 
immediately  discarded  by  the  receiving  MSG.  No  reply  is 
required . 


ECHO  (data-byte) 

This  protocol  message  requests  the  receiving  MSG  to  echo  the 
data-byte.  It  can  be  used  to  see  if  a remote  MSG  is  activel-v 
functioning.  Protocol  specifie.  that  the  data-byte  of  an  ECHO 
message  be  promptly  returned  tu  the  sending  MSG  in  a matching 
ECHO-REPLY  message. 


ECHO-REPLY  (data-byte) 
Reply  to  ECHO. 


EXPERIMENTAL  (command,  length,  data) 

This  message  provides  for  experimentation  ami  extensibility 
within  the  MSG-to-MSG  protocol.  The  com^dnd  specifies  the 
function  requested;  the  length  specifies  the  number  of  bytes  in 
the  EXPERIMENTAL  protocol  message;  data  is  information  relative 
to  the  function  requested. 
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4.  MSG-to-MSG  Protocol  for  the  ARPANET 


4.1  Implementation  of  MSG-to-MSG  paths  by  ARPANET  connections. 

Section  3 introduced  the  notion  of  "MSG-to-MSG  paths"  across 
which  '.iter-host  MSG  messrv,es  are  sent.  A single  such  MSG-to-MSG 
path  exists  between  each  pair  of  host  MSGs. 

MSG-to-MSG  paths  are  virtual  entities  in  the  sense  that  they 
are  implemented  by  ARPANET  host/host  protocol  conne  tions.  At 
any  given  time,  a given  MSG-to-MSG  path  may  be  implemented  by 
zero,  one  or  more  pairs  of  ARPANET  host/nost  connections.  The 
standard  byte  size  for  ARPANET  connection  which  implement 
MSG-to-MSG  paths  is  8 bits. 

The  set  of  ARPANET  connections  which  implement  an  MSG-to-MSG 
path  are  equivalent  in  the  sense  that  any  legal  inter-host  MSG 
message  can  be  sent  over  ary  one  of  the  ARPANET  connections  in 
the  set. 

To  send  a message  to  another  MSG,  an  MSG  selects  one  ARPANET 
connection  from  the  set  that  implements  the  MSG-to-MSG  path  and 
transmits  the  message  over  the  connection.  If  no  such  ARPANET 
connection  exists,  the  sending  MSG  must  act  to  establish  one. 
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4.2  Establishing  the  ARPANET  connections. 

A pair  of  ARPANET  connections  which  supports  an  MSG*  to  -MSG 
path  is  established  via  an  TCP  to  a "well  known"  contact  socket 
in  the  normal  way.  The  contact  socket  for  MSG  is  27  (decimal)  = 
33  (octal). 

After  a new  pair  of  connections  is  established  by  an  ICP, 
the  pair  of  MSGs  must  engage  in  a synchronization  exchange  before 
they  can  use  the  connections  to  carry  the  inter-MSG  messages 
defined  in  Section  3-  The  purpose  of  this  MSG-MSG 
synchronizat ion  is  to  allow  the  two  MSGs  to  exchange  their 
current  "incarnation"  numbers  and  any  other  information  pertinent 
to  subsequent  interaction  via  the  connection  pair. 


An  MSG  incarnation  number*  ident  ri 
MSG  service.  (We  frequently  use  the 
mean  such  a period  of  MSG  service.)  A 
and  a new  period  of  MSG  service  begins 
itself.  This  typically  occurs  after  it 
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As  noted  in  Sections  1 and  2,  MSG  process 
incarnation  number  component  which  serves  to  id 
incarnation  of  the  MSG  that  generated  the  proce 
responsible  for  managing  the  process.  The  MSG 
component  of  a process  name  is  used  to  deternin 
process  named  is  one  that  currently  exists  or  i 
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The  MSG-to-MSG  protocol  for  the  synchronizat ion  exchange  is: 

1.  The  MSG  that  initiated  the  ICP  initiates  the 

synchronization  exchange  by  using  the  send  connection 
of  the  pair  to  send  the  message: 

SYNCH  (my~incarna t ion  , your-incarna t ion  , version,  data) 
where : 


-!  ISO 


MSG-to 
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my-incarnation  identifies  the  current  incarnation 
of  the  initiating  MSG. 
your-incarna t ion  is  empty. 

version  identifies  the  version  of  the  MSG-to-MSG 
protocol  to  be  used  on  this  connection, 
data  is  other  synchronization  information. 

(To  be  defined  in  the  future.) 

2.  The  other  MSG  responds  tc  the  SYNCH  hy  usinp  the  send 
connection  of  the  pair  to  send  the  messape: 

SYNCH  (rny-incarnat ion  , your- incarnat ion  , version,  data) 

where : 

my-inca motion  identifies  the  current  incarnation 
of  the  respondinp  MSG. 

version  identifies  the  version  of  the  MSG-te-MSG 
protocol  to  be  used  on  this  connect ■>  c.i . 
your-inca rnat j on  echoes  the  incarnation  number 
specified  in  the  initiatinr  MSG's  SYNCH 
message . 

data  is  other  synchronization  information. 

After  the  synchronization  exchanre  is  completed,  the  connections 
may  be  used  to  carry  any  of  the  inter-MSG  messapes  defined  in 
Section  3 until  the  connections  are  cloned  (see  Section  4.3 
below ) . 

An  MSG  may  wish  to  ascertain  that  the  entity  at  the  other 
end  of  i new  connection  pair  is  indeed  another  MSG  before  it 
commits  any  of  its  host  resources  to  actinp  uDon  protocol 
rr.essapes  received  over  the  new  connection.  Section  ,J  . 4 below 
defines  a procedure  which  MSGs  may  use  to  reliably  authenticate 
one  another. 
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4.3  Breaking  the  ARPANET  Connections. 

A pair  of  ARPANET  conneccions  to  another  host  represents  a 
resource  which  an  MSG  may  not  want  to  keep  open  indefinitely  in 
the  absence  of  MSG  traffic.  If  an  MSG  were  to  close  a connection 
pair  unilaterally,  messages  in  transit  from  a remote  MSG  could  be 
lost  or  garbled.  A protocol  mechanism  is  defined  for  closing 
pairs  of  connections  in  an  orderly  manner  that  eliminates  the 
possibi1ity  of  such  lost  or  garbled  messages. 

T e protocol  for  closing  a pair  of  connections  is: 

1 . MSG  sends  an  MSG-to-MSG  "CLOSE"  message  over  the  send 
connection  of  the  pair  that  is  to  be  closed  and  then 
closes  the  send  connection  of  the  pair; 

2.  Upon  receipt  of  an  MSG-to-MSG  CLOSE  message  an  MSG  is 

expected  to:  close  the  connection  which  carried  the 

message;  return  a CLOSE  message  on  the  send  connection 
of  the  pair  (when  it  is  convenient  to  do  so);  and 
close  the  send  connection. 

The  protocol  exchange  defined  above  is  the  mechanism  for 
breaking  pairs  of  connections.  At  present,  we  refrain  from 
specifying  in  detail  a policy  which  defines  when  MSG  may  use  this 
mechanism . 

An  MSG  that  does  not  wish  to  communicate  with  the  entity 
that  has  initiated  an  ICP  should  respor,  . to  the  initiator's  SYNCH 
message  by  initiating  the  CLOSE  protocol  exchange.  An  MSG  might 
choose  to  do  this  if  the  synchronizat ion  data  supplied  by  the 
initiating  MSG  is  incompatible  or  if  the  initiating  entity  can 
not  properly  be  authenticated  as  another  MSG. 
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^ d Authentication  of  MSGs. 

As  noted  in  Section  H.2  above,  it  nay  be  important  for  an 
MSG  to  be  able  to  reliably  authenticate  the  entity  at  the  remote 
end  of  a pair  of  ARPANET  connections  as  another  MSG  before  host 
resources  are  committed  to  requests  made  by  that  entity.  The 
problem  here  is  one  of  mutual  authentication.  Each  entity  must 
authenticate  the  other  as  an  MSG. 

[In  the  absence  of  an  authentication  procedure,  there  is  no  way 
for  an  MSG  to  determine  whether  the  entity  at  the  remote  end  of  a 
connection  is  another  MSG  or  a bogus  process  which  follows  the 
MSG-to-MSG  protocol.  Failure  to  distinguish  between  an  MSG  and  a 
process  masquerading  as  an  MSG  could  result  in  the  inadvertent 
disclosure  of  private  information  or  unaccountable  use  of 
expensive  resources.] 

The  use  of  passwords  is  one  approach  to  MSG  authentication. 
Only  an  MSG  would  know  the  password  and  thus  be  able  to  properly 
identify  itself  to  another  MSG.  We  reject  the  password  mechanism 
as  unreliable  and  operationally  impractical  for  the  following 
reasons : 

1 . Use  of  a password  requires  that  the  password  be  stored 
in  the  sending  program  or  be  accessible  to  it  in  some 
way  thereby  increasing  the  likelihood  that  the  privacy 
of  the  password  will  be  compromised. 

2.  If  a password  is  compromised,  it  must  be  changeo  at 
both  sending  and  receiving  hosts;  this  represents  a 
synchronization  problem. 

3.  Truly  secure  authentication  would  probably  require 
passwords  for  each  pair  of  hosts;  this  would  require 
N*N  passwords  for  an  N host  NSW. 

The  mechanisms  to  be  used  for  MSG  authentication  are  based 
upon  the  properties  of  ARPANET  host/host  communication.  First, 
we  assume  that  the  ICP  is  a secure  procedure.  That  is,  we  assume 
that  a host  can  guarantee  that  MSG  is  the  only  entity  that  has 
access  so  the  MSG  ICP  contact  socket  and  that  MSG  is  the  only 
entity  that  has  access  to  the  connections  resulting  from  the  ICP. 
This  is  the  standard  assumption  made  in  the  ARPANET  regarding  the 
ICP.  Thus,  the  authenticity  of  the  entity  responding  to  an  MSG 
ICP  as  an  MSG  is  based  upon  the  security  of  the  ICP  procedure. 

The  authentication  problem  that  remains  is  that  of 
authenticating  the  entity  that  initiates  the  ICP.  Thi 
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authentication  can  be  achieved  in  a manner  similar  to  that  of  the 
ICP  responder.  Just  as  a single  well  known  ICP  contact  socket  is 
defined,  a collection  of  well  known  "ICP-from"  sockets  (i.e., 
sockets  from  which  ICPs  are  initiated)  could  be  defined.  (A 
collection  of  ICP-from  sockets  are  required  due  to  the  nature  of 
the  ICP  which  prevents  reuse  of  the  ICP-from  socket  until  the 
connections  resulting  from  the  ICP  are  discarded.)  A host  would 
be  required  to  limit  access  to  the  ICP-from  sockets  (ard  the 
connections  that  result  from  the  ICP)  to  MSG  just  as  it  is 
required  to  limit  access  to  the  ICP  contact  socket  (and  the 
connections  that  result  from  the  ICP).  If  this  were  to  be  done, 
an  MSG  responding  to  an  ICP  could  authenticate  the  initiating 
entity  as  an  MSG  by  checking  that  the  socket  from  which  the  ICP 
was  initiated  was  one  of  the  well  known  ICP-from  sockets. 

Some  hosts  find  it  inconvenient  to  limit  access  to  a 
collection  of  sockets  but  have  no  difficulty  in  controlling 
access  to  a connection  once  it  is  established.  Therefore,  a 
variation  of  the  above  approach  is  used  for  authenticating 
initiating  MSGs.  A single  send  socket  is  defined  for  MSG 
authentication;  access  to  the  MSG  authent icat ion  socket  is 
limited  to  MSG.  The  authentication  socket  is  to  be  maintained  by 
MSG  in  a listening  state.  In  re^oonse  to  an  RFC  for  the 
authentication  socket,  MSG  should  open  the  requested  connection 
'with  byte  size  = 32)  and  send  a specification  of  the  sockets 
hich  it  is  currently  using  in  active  MSG-to-MSG  connections. 

The  connection  should  then  be  closed  and  the  authentication 
socket  returned  to  the  listening  state. 

An  MSG  at  host  A responding  to  an  ICP  initiated  by  a remote 
entity  at  host  B can  authenticate  that  entity  by  the  following 
simple  procedure: 

1.  The  MSG  at  A notes  the  remote  sockets,  SI  and  S2 , used 
in  the  connections  that  result  from  the  ICP. 

2.  It  opens  a connection  to  the  authentication  socket  at 
B,  reads  the  socket  specification  that  the  MSG  at  B 
sends,  and  closes  the  authentication  connection. 

3.  If  the  remote  sockets,  31  and  S2 , are  included  in  the 
specification  then  the  entity  at  B is  an  MSG; 
otherwise,  it  is  not.  (Note  that  when  the  MSG  at  B 
initiates  an  ICP  to  the  MSG  at  A,  it  must  remember  the 
sockets  it  uses  so  that  it  can  include  them  in  the 
socket  specification  sent  to  the  MSG  at  A.) 
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The  reliability  of  this  authentication  procedure  depends 
upon  the  ability  of  host  B to  insure  that  only  MSG  has  access  to 
the  authentication  socket  and  to  the  sockets  named  in  the 
specification  sent  over  the  authentication  connection.  (This  is 
exactly  what  host  B must  do  to  insure  the  security  of  ICPs  to  its 
well  known  contact  sockets.)  In  addition,  it  requires  that  the 
MSG  at  A have  means  to  reliably  determine  sockets  in  use  at  the 
remote  end  of  connections.  Socket  identity  is  part  of  the 
information  NCPs  must  exchange  in  order  to  open  a host/host 
connection.  Thus,  the  socket  information  is  available  to  the  NCP 
at  A.  The  authenticity  of  the  information  depends  upon  the 
trustworthiness  of  the  NCP  at  B.  We  assume  NCPs  to  be  secure; 
if  they  were  not,  there  could  be  no  reliably  secure  communication 
between  ARPANET  hosts. 

Tne  MSG  authentication  socket  is  29  (decimal/  = 35  (octal). 
The  specification  of  MSG  sockets  returned  over  the  authentication 
connection  may  be  a range  of  sockets  or  a list  of  sockets.  A 
socket  range  is  transmitted  as  3 bytes: 

byte  1 : 

0 indicates  ^ange  spec 
byte  2: 

Sa 

byte  3: 

Sb 

All  sockets  within  the  range  defined  by  Sa  and  Sb  (including  Sa 
and  Sb ) are  MSG  sockets.  A list  of  N sockets  is  transmited  as 
N+2  bytes: 


byte  1 : 

1 indicates  list  spec 
byte  2: 

N the  number  of  bytes 
byte  3: 

51 

byte  *4 : 

52 


that 


follow 


byte  N+2: 

3N 

The  MSG  sockets  are  SI,  S2,  ...,  SN . 
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4.5  Error  Control  for  MSG-to-MSG  Paths 

ARPANET  Lost  to  host  communication  is  reasonably  reliable. 
However,  communication  failures  can  occur.  For  example, 
host/host  messages  are  lost  occasionally.  A lost  host/host 
message  may  manifest  itself  at  the  MSG-to-MSG  path  level  as  a 
"hung”  connection  (if  the  message  lost  was  a host/host  allocate) 
or  cs  a totally  or  partially  lost  MSG-to-MSG  message  (if  the 
message  lost  was  a host/host  data  message). 

In  addition,  communication  between  a pair  of  hosts  can  be 
interrupted  temporarily.  The  interruption  may  be  the  result  of  a 
transient  network  failure  (e.g.,  the  source  or  destination  IMP 
crashes  and  is  restarted)  or  a transient  host  service 
interruption  (e.g.,  TENEX  hosts  occasionally  experience  BUGCHK 
interruptions  and  resumptions).  At  the  MSG-to-MSG  level  this  may 
manifest  itself  as  a spontaneously  closed  host/host  connection. 

If  the  connection  was  being  used  at  the  time,  this  could  result 
in  a lost  or  garbled  MSG-to-MSG  message. 

Mechanisms  to  insure  reliable  communication  in  an 
environment  where  messages  can  be  lost  are  reasonably  well 
understood.  These  mechanisms  typically  require  positive 
acknowledgement  cf  all  messages  and  the  use  of  a time  out  and 
retransmission  scheme.  This  generally  requires  that  the 
communicating  entities  (in  this  case  pairs  of  MSGs)  use  unique 
identifiers  or  sequence  numbers  to  identify  messages  in  transit 
and  employ  techniques  for  detecting  duplicate  messages  (the 
message  may  have  made  it  but  its  acknowledgement  may  have  been 
lost).  Note  that  these  message  identifiers  serve  to  identify 
individual  inter-MSG  messages  and  are  therefore  different  from 
the  transaction  identifiers  used  in  the  inter-MSG  protocol  to 
identify  transactions  that  involve  a number  of  inter-MSG 
messages . 

The  question  here  is: 

Should  such  a reliable  t ransmission  mechanism  be  used 
for  error  control  on  the  MSG-to-MSG  paths? 

Our  position  with  regard  to  error  control  for  MSG-to-MSG  paths 
is : 

1.  The  most  effective  error  control  mechanism  for  the 
MSG-to-MSG  application  is  that  described  by  Cerf  and 
Kahn  (i.e.,  that  used  in  the  InterNet  or  TCP  protocol). 
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2.  The  overhead  incurred  by  using  a TCP-like  error  control 
mechanism  would  not  significantly  degrade  performance 
for  the  NSW  MSG  application. 

3.  Use  of  a TCP-like  mechanism  would  approximately  double 
the  time  and  effort  required  to  implement  inter -host 
MSG  . 

4.  The  TCP  mechanism  can  be  made  orthogonal  to  the 
MSG-to-MSG  protocol  and  to  a properly  designed  MSG 
implementation.  That  is,  the  information  required  to 
enable  TCP-like  error  control  would  envelope  inter-MSG 
messages.  We  estimate  that  5 or  6 additional  8 bit 
bytes  are  required  for  each  inter-MSG  message  to 
support  TCP-like  error  control.  Furthermore,  we 
believe  that  the  processing  required  to  perform  the 
error  control  function  can  occur  in  series  with  the 
"higher  level"  processing  required  to  implement  the  MSG 
protocol . 


It  is  not  clear,  at  present,  whether  error  control  stronger 
than  that  normally  provided  by  ARPANET  host  to  host  communication 
v/ ill  be  required  by  the  NSW  application.  Therefore,  the  initial 
inter-host  MSG  specification  does  not  include  TCP-like  error 
control  for  the  MSG-to-MSG  paths  nor  does  the  transmission  format 
for  inter-MSG  messages  include  fields  for  the  information 
required  to  support  TCP-like  error  control.  However,  the  MSG 
implementations  should  be  done  with  the  expectation  chat  it  may 
be  necessary  to  add  TCP-like  error  ccutrol  later,  should 
experience  indicate  that  the  lack  of  error  control  for  the 
MSG-to-MSG  paths  is  resulting  in  unacceptable  performance. 
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5.  MSG-to-MSG  Transmission  Formats  for  the  ARPANET 

This  section  specifies  in  detail  the  formats  for  the 
MSG-to-MSG  protocol  commands  as  sent  over  ARPANET  connections. 
Only  the  syntax  of  the  commands  is  specified  here;  for  a 
discussion  of  the  semantics  of  the  MSG-to-MSG  protocol  see 
section  3 of  this  document. 
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5.1  General  format  for  MSG-to-MSG  messages: 

An  MSG-to-MSG  message  is  a sequence  of  8 bit  bytes.  The 
first  two  bytes  contain  the  length  of  tne  message  in  bytes;  the 
third  byte  is  a command  code  that  identifies  an  MSG-to-MSG 
protocol  item;  and  the  remaining  bytes  contain  information 
relative  to  the  command. 


* length  * command  * data 


1 length  - 3 
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5.2.  Formats  for  Message  Components 
1 . Process  names : 
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* host  # host 

* * incarnation  it 


# process 

* instance 


* count  * string 

it  * * 


* 
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2 2 


2 


count 


Host  is  a 16  bit  host  address.  (Whether  the  host  address  is  an 
ARPANET  host  address  or  an  NSW  host  address  whose  correspondence 
to  an  ARPANET  host  address  is  defined  by  a table  MSG  maintains  is 
to  be  decided  shortly.)  If  MSG  is  modified  to  allow  processes 
with  no  generic  names,  the  null  generic  name  will  be  represented 
by  a zero  length  string. 
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penerically  addressed  message  the  destination  process 
y partially  specified.  Either  only  the  generic 
ss  is  specified,  or  only  the  host  and  generic  class 
ed  in  a generically  addressed  message.  The  other 
are  left  unspecified.  "Unspecified"  is  a special 
in  generically  addressed  messages  for  host,  host 
it,  and  process  instance  v.  Unspecified  is 
by  two  zero  bytes. 


When  a process  name  appears  as  the  parameter  of  an 
MSG-to-MSG  message,  the  host  component  of  the  name  need  not  be 
represented  explicitly  since  it  is  implicit  from  the  hosts  of  the 
sending  and  receiving  MSGs.  There  are  two  representations  for 
process  names  a^  the  MSG-to-MSG  level:  normal  and  compact.  The 

only  difference  in  the  two  is  the  represent  at ion  of  the  generic 
process  class.  In  the  normal  represenat ion  the  generic  class  is 
represented  by  a string  whereas  in  the  compact  form  it  is 
represented  by  a one  byte  generic  class  code.  MSG 
implementations  must  be  able  to  deal  T.;ich  both  representations 
for  process  names.  The  compact  repre senta t i on  is  defined  to 
allow  for  greater  transmission  efficiency.  Use  of  the  generic 
codes  is  internal  to  MSG  in  the  sense  that  the  codes  never  appear 
in  a process  name  given  by  MSG  to  an  MSG  process  or  accepted  by 
MSG  f rom  an  MSG  process.  Generic  class  codes  for  the  NSW  will  be 
defined  in  the  near  future. 


f or 
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Normal  Format:  count  < 128  (5  + count  bytes) 


* hosL  * process  * count  * string  * 

* incarnation  # * instance  # * * * 


2 2 1 count 


Compact  Format:  Generic  code  >=  128  (5  bytes) 


* host  * process  * generic  * 

* incarnation  # * instance  //  * code  * 


2 2 1 

Generic  code  = 128  + n (n  < 128) 

where  n = integer  which  specifies  a generic  class 

n = 0 - null  (i.e.,  process  has  no  generic  name). 


2.  Host  Incarnation  //: 

16  bit  (2  byte)  number. 

0 = unspecified  (used  for  genericallv  addressed  messages) 

1-255  reserved  for  special  use 


3.  MSG  transaction  Identifiers  (source-id.  destination-id) 


* MSG  id  * 


16  bit  (2  byte)  number. 
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. Alarm  code 


* acode  * 

2 

16  bit  (2  byte)  number. 
5.  Failure/Rejection  codes 


* reason  * 


16  bit  (2  byte)  number. 

See  descriptions  of  individual  messages  for  discussion  of 
specific  codes.  Values  have  not  yet  been  assigned,  nor 
those  codes  given  necessarily  exhaustive. 
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5.3  Identifying  Transactions. 

In  the  format  specifications  that  follow  all  inter-MSG 
messages  concerned  with  inter-process  transactions  carry  the 
source  and  destination  process  names  as  well  as  the  MSG  source 
and  destination  transaction  identifiers.  The  redundancy  provided 
by  the  process  names  is  useful  to  an  MSG  in  detecting  and 
recovering  from  protocol  errors  or  violations  resulting  from 
malfunction  of  a remote  MSG.  With  the  exception  of  MESS 
messages,  all  protocol  messages  will  fit  into  a single  ARPANET 
packet  (assuming  the  compact  representation  of  process  names  or 
generic  names  of  a few  characters);  hence,  the  cost  associated 
with  the  redundancy  is  not  great. 
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5.4  MSG-to-MSG  protocol  messages 

1.  ME3S( src-proc , dst-proc,  handling,  src-id,  dst-id,  message) 
«'iength"*"MESs''’spc-id  * dst-id  » First  byte^* Jandling 


* src-proc  * dst-proc  * message  * 


5+ j 


5+k 


M 


length  = 19+j+k+M 

j = # chars  in  source  :enenc  name 
k = # chars  in  destination  generic 
format . 

MESS  =8  (10  octal ) 

Handling  = bit  flags  (numbered  0-7  from 


/ 0 if 
name  / 


compact  format . 
0 if  compact 


left  to  right) 


bit 
bit 
bit 
bit 

First  byte 


generically  addressed  message 

- sequenced  message 

- synchronization  mark  on  message  hoi D1 

- immediate  decision  on  delivery  (prombit  HOLD) 
- Position  of  first  byte  of  the  message  (zero 


the  position  of  the 
MSG-to-MSG  message) 


ill  ot  j ~ i-u^ 

first  bvte  of  the  length  field  of  the 


2. 


MESS-OK ( src-proc , dst-proc,  src-id) 


* length 
2 


’*  MESS-OK  * src-id  1 src-proc  * dst-proc^ 

1 2 5+i 


length  = 15+j+k 
MESS-OK  - 9 (11  octal) 
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3.  MESS-REJ ( src-proc , dst-proc,  src-id,  reason) 


* length  * MESS-REJ  * src-id  * reason  * src-proc  * dst-proc  * 


2122  5+j  5+k 

length  = 17+j+k 
MESS-REJ  = 10  ( 12  octal) 
reason  = To  be  specified,  but  including; 
dst-proc  unknown 
no  buffer  space 

message  queue  for  process  full 


4.  MESS-HOLD ( src-proc , dst-proc,  src-id,  dst-id) 

* length  * MESS-HOLD  # src-id  * dst-id  * src-proc  * dst-proc  * 

2 12  2 ^ 5-*k 

length  = 17+j+k 
MESS-HOLD  = 11  (13  octal) 

5.  H0LD-0K ( src-proc , dst-proc,  src-id,  dst-id) 

* length  * H0LD-0K  * src-id  * dst-id  * src-proc  * dst-proc  * 

2 122  5+j  5+k 

length  = 17+j+k 
H0LD-0K  =12(14  octal ) 


MSG-to-MSG 
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6.  MESS-CANCEL ( src-proc , cist-proc,  sro-^d.  dst-id,  reason) 


* length  * MESS-CANCEL  * src-id  * dst-id  * reason 


2 1 2 2 2 


* src-proc  * dst-proc  * 


5+ j 5+k 

length  = 19+j+k 
MESS-CANCEL  = 13  (15  octal) 
reason  = To  be  specified,  but  including: 
src-proc  unknown 
f ” "’-id  unknown 
.essage  rescinded 
src-proc  terminated 
no  buffer  space 

7.  XMIT ( src-proc  , dst-proc,  src-id,  dst-id) 


* length  * XMIT  * src-id  * dst-id  * src-p  oc  * dst-proc  * 
2122  5+j  5+k 


length  = 17+j+k 
XMIT  = lij  (16  octal) 


8.  AL  ARM ( src-proc  , dst-pr  : . src-id,  acode) 

* length  * ALi.  H src-id  * acode  * src-proc  * dst-proc  * 

2122  5+j  5+k 

length  - 17+j+k 
ALARM  = 16  (20  octal) 
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9.  ALARM-OK ( src-proc , dst-proc,  src-id' 

* length  * ALARM-OK  * src-id  * src-proc-  * dst-proc  * 

2 1 2 5+3  5+k 

length  = 15+j+k 
ALARM-OK  = 17  (21  octal) 


10.  ALARM-REJ ( src-proc , dst-proc,  src-id,  reason) 


* length  * ALARM-REJ  * src-id  * reason  * src-proc  * dst-proc  * 
2 1 2 2 5+ j 5+k 


length  = 17  + vi+k 
ALARM-REJ  = 18  (22  octal) 
reason  = To  be  specified,  but  including: 
dst-proc  unknown 
dst-proc  not  accepting  alarms 
alarm  already  queued  for  dst-proc 


11.  CONNECTION-OPEN ( src-proc , dst-proc,  src-id,  dst-id,  conn-id, 
type,  socket.) 


* length  * CONN-OPEN  * src-id  * dst-id  * conn-id  * type 
2 1 2 ? 2 2 


* socket  * src-proc  * dst-proc  * 


4 5 + vi  5+k 

length  - 25+j+k 

CONN-OPEN  = 20  (24  octal) 

type:  0 - Teletype  (TELNET) 

bit  0 + s’ze  - binary  send/receive  pair  + size 

bit  1 + size  - binary  send  + size 
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bit  2 + size  - binary  receive  + size 
socket:  32  bit  socket  number  = N 

Teletype  N = odd  = send  socket 

N+1  = even  = receive  socket 
Binary  send/receive  pair  (same  as  Teletype) 

12.  CONNECTION-CLOSE(src-pr oc , dst-proc,  src-id,  dst-id,  reason) 


# length  # CONN-CLOSE  * src-'  * * dst-id  # reason  * src-proc 


2 1 2 2 2 5+j 


* dst-proc  * 


5+k 

length  = 19+j+k 
CONN-CLOSE  = 21  (25  octal) 
reason  = To  be  specified,  but  including: 
normal  close 
src-proc  terminated 
timeout  of  open 
byte-size  mismatch 
type  mismatch 

13.  CONNECTION-REJECT(src-proc , dst-proc,  src-id,  dst-id,  reason) 


* length  * CONN-REJ  * src-id  * dst-id  * reason  * src-proc 


2 1 2 2 2 5+j 

* dst-pr-v.  * 


5+k 

length  = 19+j+k 
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CONN-REJ  = 22  (26  octal) 
reason  = To  be  specified,  but  including: 
dst-proc  unknown 
dst-id  unknown 
byte-size  invalid 
type  invalid 
timeout 


14.  NOP 


* length  * NOP  * 


2 1 


length  =:  3 

NOP  =0(0  octal) 


15.  ECHO ( data  byte) 


* length  * ECHO  * data  byte  * 


2 1 1 

length  - 4 

ECHO  =1(1  octal ) 


16.  ECHO-REPLY ( data  byte) 


* length  * ECHO-REPLY  * data  byte  * 
2 1 1 
length  = 4 

ECHO-REPLY  = 2(2  octal  ) 
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17.  EXPERIMENTAL ( command , length,  data) 

* length  * EXP  # command  * data  * 

2 1 < N 

length  = 4+N 

EXP  = 24  (30  octal) 

18.  SEND-STATUS(src-proc , dst-proc,  src-id) 


* length  * SEND-STATUS 

* src-id 

* src-proc 

* dst-proc  * 

2 

1 

2 

5+ j 

5+k 

length  = 15+j+k 
SEND-STATUS  = H (4  octal) 

STATUS-OK (src-proc,  dst. 

-proc,  src 

-id,  statu 

s bytes) 

* length  * STATUS-OK  * 

src-id  * 

src-proc  * 

dst-proc 

2 

1 

2 

5-M 

54k 

* status  bytes  * 


N 

length  = 15+j+k+N 
STATUS-OK  = 5(5  octal ) 
status  bytes  = (to  be  defined) 

20.  STATUS-REJ ( src-proc , dst-proc,  src-id,  reason) 

* length  * STATUS-REJ  * src-id  * reason  * src-proc  * dst-proc  * 
2 1 22  5+ j 5+k 

length  = 17+j+k 
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STATUS-REJ  = 6 (6  octal) 
reason  = To  be  specified, 
dst-process  unknown 


but  including: 


21.  CLOSE ( ) 


* length  * CLOSE  * 


2 1 

length  = 3 
CLOSE  = 7 (7  oct 


22.  SYNCH ( sender 's  incarnation  #,  receiver's  incarnation  #, 
version  #,  data) 


* length  # SYNCH  * sender  # * receiver  # * version  # * data  # 
2 1 2 2 2 N 


length  = 9+N 
SYNCH  = 3 (3  octal) 

S'"  nder /receiver  #'s  = Host  incarnation  #'s  = 2 bytes 
version  # = version  of  MSG  protocol  to  be  used  by  the  sending 
MSG  = 2 bytes 

data  = additional  synchronization  information  (to  be  defined) 


23.  PTCL-ERR (error  code,  bad  message) 


* length  * PTCL-ERR  * error  code  * bad  message  * 
2 1 2 N 


length  = 5+N 

PTCL-ERR  = 25  (31  octal) 

error  code  = To  be  specified,  but  including: 
command  not  implemented 
command  unknown 
command  syntax  er~or 
bad  message  = The  Dad  MSG-MSG  message. 
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5.5  Summary  of  Commands 


Code 
Dec  Oct 

Command 

Length 

0 

0 

NOP 

3 

1 

1 

ECHO 

4 

2 

2 

ECHO-REPLY 

4 

3 

3 

SYNCH 

9+N 

4 

4 

SEND-STATUS 

15+j+k 

5 

5 

STATUS-OK 

1 5+  i+k+N 

6 

6 

STATUS-REJ 

17+j+k 

7 

7 

CLOSE 

3 

8 

10 

MESS 

19+ j+k 

9 

1 1 

MESS-OK 

15+j+k 

10 

12 

MES3-REJ 

17+j+k 

1 1 

13 

MESS-HOLD 

17+j+k 

12 

14 

H0LD-0K 

17  + Uk 

13 

15 

MESS-CANCEL 

19+ j+k 

14 

16 

XMIT 

17+j+k 

15 

17 

reserved 

16 

20 

ALARM 

17+j+k 

17 

21 

ALARM-OK 

15+  j + k 

18 

22 

ALARM-REJ 

17+j+k 

19 

23 

reserved 

20 

24 

CONN-OPEN 

25-*-  j i-k 

21 

25 

CONN-CLOSE 

1 9+ j+k 

22 

26 

CONN-REJ 

1 9 + j+k 

23 

27 

reserved 

24 

30 

EXP 

4 + N 

25 

3< 

PTCL-ERR 

5 + N 

j = Extra  bytes  needed  if  src-proc  name  is  not  in  compact  format, 
k = Extra  bytes  needed  if  dst-proc  name  is  in  compact  format. 
N = Number  of  bytes  in  data  or  message  contained  in  command. 
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